
Road Map
========

Version 1   	- Support for all standard GTK 1.0 widgets.

Version 1.1	- GTK 1.1/1.2 (Glade now compiles and runs with GTK 1.1)
		- Try to use conditional compilation to support GTK 1.0 as
		  well for now, until GTK 1.2 is released at least.
		- New widgets - GtkCTree, GtkFontSelection/Dialog, GtkPacker,
		                GtkAccelLabel, GtkProgress.
		- Accelerators have been changed.
		- *Spinbutton has changed slightly.
		  Also has new properties?
		- Progress bar has several new properties.
		- GtkButton is now a subclass of GtkBin, and has a 'relief'.
		  GTK_BUTTON(widget)->child is deprecated.
		- GtkTable has better support for dynamic changes.

Version 1.2 	- Support for Gnome & custom widgets.
		- hopefully the same binary could support both, by dynamically
		  loading any Gnome stuff.
		- Use gettext both within Glade and optionally in the source
		  code output (Glade now uses gettext itself).
		- Follow Gnome style guidelines, e.g. dialog box layout,
		  spacing, standard pixmaps on buttons, menu layout,
		  accelerators, session management. 
		- Gnome also has its own initialization functions, which would
		  also have to be output in the app's source code.

Version 2   	- Use of Arg mechanism both within Glade and in the resulting
		  source code. This would need major changes, and depends on a
		  full implementation of Args in GTK (see doc/generic.txt for
		  some problems which may occur with this).
	      	- Dynamic loading of widget libraries (this also depends on a
		  full implementation of Args in GTK (see doc/notes.txt)).
		- A library which can load the XML interface file and create
		  the interface at run time. We need to start thinking ahead
		  and writing Glade code ready to go in a library.
		  Would it be possible to create several instances of the
		  same window? Maybe the library should just load the XML
		  initially, then create windows on demand.

Long Term Ideas - NOTE - these are just ideas!
		- Data-bound widgets to connect to a free SQL server.
		- Integrated source code editor with syntax-highlighting.
	      	   Support for more of the development process - building,
		   running, debugging, version control. We will probably
		   integrate with the gIDE app to get these.
		- Support for several languages (those with GTK bindings):
		    C, C++, Guile, Objective-C, Perl, Python.
		  note that use of the Arg mechanism would probably make this
		  a much easier task. Could possibly allow interpreted
		  languages to be run & debugged within Glade?
		- Wizards to speed creation of common structures - e.g. for a
		  dialog box we can have options for whether the buttons are
		  on the right or bottom, which buttons to add - combinations
		  of 'OK', 'Cancel', 'Close' & 'Apply'.
		- Allow easy creation of configurable interfaces, so that
		  the user can change the menus & toolbars. i.e. there are a
		  number of 'actions' and a number of toolbar icons. The
		  developer creates the default menu structure and toolbar
		  layout(s). The user selects a 'Configure' menu item and
		  can reorganise the menus & toolbars. May need to specify
		  that some things can't be changed.
		- Include option to add some common code - e.g. a recent
		  file list on the File menu, with functions to add files to.


Major Things To Do
==================

Loading/Saving projects
	- almost done now - see doc/file_format.txt.
	- need to complete error handling code - showing all errors and
	  positions in input file in a dialog.
	- styles not quite finished.
	- pixmap pathnames should not be absolute, or project is not portable.

Writing Source code
	- Glade outputs C itself. Converters are currently being developed for
	  C++, Perl & Python. (Anyone for Obj-C and Guile?)
	- see doc/source_code.txt

	C Output:
	- doesn't do styles.
	- dialog box to set project name, source directory, and other options:
	  set widget names, add to component hash, license (GPL), output
	  configure.in & Makefile.am & standard automake files.
	- create files expected by automake - README, NEWS, AUTHORS
	- write shell script to build ? - like Gnome's autogen.sh
	  Need to do: aclocal, automake -a (--foreign), autoconf, ./configure,
	  make.
	- need to support updating a previously written project -
	  Remember which signals have been written so we only add new ones.
	  Keep a 'last modified' time for each signal and compare it with the
	  signals source file to see if the signal should be output.
	  What about if a signal is updated?
	- write signal handlers for different components in different files?
 	  option?
	- clist - use new_with_titles if all titles are simple labels?
	- use structs to hold the component's widgets, rather that putting
	  them in the component's data hash? All those get_widget() calls
	  are annoying, and you forget the widget names.
	  (But this may break existing code - use an option?)
	- could even allow turning a component into a widget.
	- write out table children in a decent order, i.e. top left first.

Menu Editor
	- for editing menu bars and popup menus (+ accelerators + submenus).
	- awkward since menuitems can contain any widget.
	- possibly allow just text at first, or use a list widget and edit
	  that just like other windows are edited + commands to add/remove/move
	  items.
	- mostly done. Will add support for pixmaps in future.

Toolbar Editor
	- for editing icons, text & widgets on toolbars.
	- Similar to menus in that I think any widget can be used.
	- Could possibly edit in place using popup menu commands.

Other Special Editors
	- CList, List, Combo, OptionMenu, Tree, others?
	- Notebook menu items? reordering pages?
	- Table row & column spacings?
	- Combo & OptionMenu can be created with text items at present,
	  but other widgets could possibly be used.
	- could edit lists like normal widgets, plus popup menu commands
	  to add/remove/move items.
	- it may not be that useful to allow editing of CLists and Trees
	  since they are likely to be created dynamically from data anyway.

Popup Context-Sensitive Menus
	- currently only allows selection & deletion of widgets.
	- should also include commands for:
		*removing labels from buttons so other widgets can be used
		*inserting rows/cols in boxes.
		*inserting/deleting rows/cols in tables.
		converting boxes into tables?
		inserting boxes above widgets? - so other widgets can be added.
		*inserting alignments/event boxes above widgets.
			(alignments useful for all widgets except Misc ?)
			(event boxes useful for widgets without windows)
		insert frames/tables above widgets and removing?
		editing special widgets - menu/toolbar/clist/list as above.
		changing position of buttonbox in a window right/bottom?

Custom Widgets
	- need to allow external widgets to be added easily.
	- my current idea is to let users specify custom widgets in a file
	  which would be loaded at startup.
	  The file would give a possible icon for the widget, a name (tooltip),
	  and a list of properties with types (+ ranges for ints/floats,
	  and lists of choices & values).
	  The editor would show the custom widget as a special graphic rather
	  like the placeholders.
	  The user could position it and set padding/size etc.
	  When the source code is written, a function is called to create
	  the widget with the properties which have been set. The user has
	  to supply this function.
	  Actually, I might wait until the Args mechanism is in place and use
	  that.
	- what about custom dialogs like GnomeMessageBox?
	- how do we save custom widgets so that programs can create source
	  code? - other programs will have to know about the custom widget
	  file as well. - Use similar format to project files for easy parsing.

Cut/Copy/Paste
	- Having used Glade myself a bit recently I think this is badly needed!
	- We also need a clipboard/scratchpad to hold a number of 'cut'
	  widgets, to make it easier to rearrange the layout.
	- use the output from the save command to store the widgets cut/copied
	  & keep a flag to indicate if the names are valid? - if we paste the
	  widgets we may need to change the names so they are all unique.
	- might be nice to copy rows/cols of a table/clist.
	- use the standard X selection, so we can copy/paste across several
	  instances of Glade.

Undo/Redo
	- ideally want a multi-level undo feature, so for each command which
	  changes the state we need to store the old state and an undo function
	  in an undo/redo stack.
	- But if the user spins a property value in a spinbutton we only want
	  one or possibly a few entries in the undo stack. Similar for editing
	  textual properties. i.e. compress all changes to the same property,
	  if it is a text or spinbutton property (not for choices).
	- Since there are only a few actions which change the state - creating
	  & deleting widgets & changing properties, this shouldn't be too hard,
	  but we need a clever generic way to handle it all without adding more
	  functions to the GbWidgets.

Hierarchical View of Widgets
	- use a tree to display the widget hierarchy of a window, allowing
	  widgets to be selected & their properties shown (partly done).

RC editor
	- allow RC files to be created in a simple way.
	- e.g. specify that all buttons use a certain style.
	- need a style editor, like in the properties window, and a 'rules'
	  editor to specify which widgets use which styles.
	- probably best to wait for GTK themes.

Changing properties of multiple widgets at once
	- when multiple widgets are selected, show the common properties
	  and allow them to be changed for all the widgets.
	- fairly complicated - leave 'til later.


Minor Things To Do
==================
	Still quite a few bits to finish off and bugs to sort out:

	- Need to make it easier to change the layout - at the moment
	  it works OK if you know the exact layout you want, but its not
	  very good for experimenting with different layouts. Need ways of
	  moving children of boxes up/down or left/right. Children of tables
	  can be moved around by using the property editor, but its not ideal.
	  Drag-and-drop would be better, just like applets can be moved in
	  the Gnome panel.

	- The fixed container still has several problems.

	- Don't get motion_notify events in all windows (or button presses -
	  combos' arrow), so we can't always set the appropriate cursor
	  (or start a resize drag).
	- Can't resize hbox/table in a fixed - a child is always selected
	  instead.

	- Table special child properties - add row/col spacing? - an easy way
	  to set spacings. But we output the spacings as properties of the
	  table rather than the children.
	- Notebook - add num pages property?

	- Style names - allow multiple widgets to use the same style - not
	  quite working yet - need to propagate style when widget created.
	  Also set_style() is incorrect?

	- Delete key - shouldn't delete widget if it is an entry/text?
	  I think we'll stop most signals from getting to widgets, and have
	  a test mode so that people can play with the interface.

	- Check that widget names are unique at some point? Otherwise there
	  may be problems with the source code, depending on how it is written.

	- (Fixed?) Apparently there's a problem with multiple-depth displays -
	  placeholder pixmaps need to be recreated for each window?
	  May be the same problem with pixmap widgets, and bg pixmaps.

	- command-line arguments - options to load a file, output the source
	  code etc. (i.e. to be used in a Makefile)

	- adding scrollbars to a text widget.

	- notebook - sometimes the tabs are not displayed.

	- moving combo in a fixed - grabs pointer.

	- Clist column justification.

These aren't so important:

	- better handling of the window size - keep shrink/grow/autoshrink
	  separate from shown interface. changing the window size within
	  Glade doesn't always change the window size at present.
	- gbwidgets write_source() - if create_widget not set should still set
	  all the properties, including those normally set in new().
	- gb pixmaps - do we need to recreate if the background color changes,
	  so that the transparency is set properly?
	- signals - if the X event mask needs to be set to receive a signal
	  added by the user, prompt to set it.
	- signals - handler should be a combo with a few common entries,
	  e.g. "gtk_widget_destroy", "gtk_widget_destroyed".
	  object & data should be combos which contain all the widgets in the
	  current component.
	- use imlib to allow use of gifs/jpegs/pngs etc.?
	- Project file - save current state of interface - which windows are
	  open and their positions.
	- Deleting multiple widgets - only deletes 1 at present.
	- Moving multiple widgets in a Fixed - only moves 1 at present.
	- In a Fixed container, Alt + button press should select any widgets
	  behind (since they can overlap).
	- Tooltips - setting fg/bg colors, delay time & if enabled.
	  Should be properties of toplevel windows/dialogs?
	  Use different tooltips colors - light blue for Glade tooltips,
	  yellow for toolips of created widgets?
	  Toolbars have their own tooltips, so maybe they should have the
	  tooltip properties as well.
	- TipsQuery - what is it?? do we need it?
	- Should alignments/event boxes be distinguished by using a different
	  background for the placeholder? Otherwise you can't tell it's there.
	- Don't put 'Delete' in popup menu for placeholder children of a paned.
	  Other widgets as well? CList titles, File/Colorsel buttons.
	- Alignment toolbar for fixed containers.
	- Ignore SIGINT (or user may lose work)
	- Auto-save (like emacs) - so user doesn't lose work!
	- If the user types while the mouse is pointing at a label (button etc)
	  change the label's text (i.e. pass keyboard events to the relevant
	  text property, and show that notebook page.)
	- Minor memory leaks in windows/dialogs - the wmname & wmclass strings
	  in the object data hash should be freed when the widget is destroyed.
	- Minor memory leak when loading - if an error occurs signals/accels
	  lists should be freed.
	- 'Reset' buttons for x, y, width, height to reset them to their
	  default size (i.e. set to -1 for x & y or 0 for w & h).
	- Set widget's sensitivity? We'd need extra code to get events for
	  insensitive widgets since Gtk doesn't pass them events.
	  Couldn't let windows become insensitive as we will never get events
	  (unless we use add our own event filter using GDK).
	- background color/pixmap - only relevant if widget has a window
	  Maybe I should make this insensitive so it doesn't confuse people.
	- viewport - difficult to edit children since can't scroll it.
	- minor redrawing problems:
	  - if a widget has a window that doesn't cover its allocation, then
	    it doesn't get expose events for all its allocation and so the
	    selection rectangle can get messed up (e.g. by moving the window).
	- support drag-and_drop for the colors in the style properties page.
	- change border_width - scrollbars etc. not redrawn properly.
	- clist - titles active property?
	- if you add an event box/alignment above a widget, its 'Place'
	  properties are changed. The event box/alignment should get the
 	  original place properties.
	- redrawing is still awful - add accelerator (C-l?) to redraw window.

	- Help files - use DocBook and generate HTML as default format.
	  Use GtkXmGTML widget, or if we run under Gnome use the help system.
	  doc/manual.txt contains a few notes.
	  Ideally tie in with GTK docs. e.g. if you press F1 with the mouse
	  over a widget in the palette, it will bring up the page in the GTK
	  docs describing the widget.

Damon, 3 October 1998
