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

Loading/Saving projects
	- almost done now - see doc/file_format.txt.

Writing Source code
	- C first, other languages later hopefully (any volunteers??).
	- Write create_<window_name>() functions for all windows in one file
	  and write prototypes of signal handlers in another file which the
	  user can edit. Could alternatively put each window in a separate
	  file.
	- Hopefully it would be possible to edit the interface again after
	  code has been added by the user. If the user doesn't change the
	  window creation code that would be possible. New signal handler
	  prototypes could be added on to the end of the handlers file.
	- Need to allow the creation of multiple windows of the same type,
	  so need to be careful about global variable naming. My current
	  idea is to use the object hash of each window to store pointers
	  to all the widgets in the window, using the name as the key. That
	  would make it easy for the programmer to access any widget.
	- Also need to be careful about the order of some Gtk commands.
	  Some of them need the widget to be realized first etc.
	  e.g. gtk_widget_grab_default() must be after setting CAN_DEFAULT.
	  + need to realize a widget to create pixmaps.
	  + need to realize a text widget before setting the text?
	- Output resource '.rc' files?
	- See the section on Custom widgets.
	- Ouput Makefile, or better a Makefile.am and configure.in?
	- Should pixmaps be included in the source, or loaded from a file
	  when the program is run? Project option?

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.

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:
		(Done)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 above widgets?
		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.
	- 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
	- 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.
	- might be nice to copy rows/cols of a table.

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.
	- 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.

Gnome
	- would like it to be a Gnome app as well as supporting just Gtk.
	- What is needed to convert to a Gnome app? Use gettext()? Also need
	  to follow Gnome style guidelines, e.g. dialog box layout, spacing,
	  pixmaps on buttons, accelerators, session management?

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

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.

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:

	- SEGV if we add multiple widgets very quickly - occurs in
	  gtktext.c:expose_text() - cache == NULL.
	- SEGV in gtk_preview_draw_row() - gtk_color_24() when showing
	  colorsel in 24 bit display.

	- Can't select insensitive widgets, since Gtk doesn't pass them
	  button_press events. Need to get the event widget myself to sort
	  this out. What if the window is made insensitive? - won't get event,
	  so we can't let a window become insensitive - use a flag to store it.
	- Width/height - keep flag to indicate if user has changed these
	  properties, and allow setting to -1 to return to default.
	- Dialogs - need to make sure the vbox and action area aren't deleted,
	  and that we don't save them, since they are created automatically.
	  But should we allow their properties to change? e.g. borderwidth -Yes
	  Or don't use dialogs. Just create a Window with some widgets in.
	- CList: deleting titles - don't allow.
	- Selecting/resizing spinbutton/gammacurve/curve in a fixed container -
	  problems - these have several X Windows so we need to use the
	  allocation & display the selection in parent fixed widget 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? - also need a way of changing
	  the current page, especially if the tabs are turned off.
	- Radio button groups - how to specify in properties? a string ID? Yes
	  Use a combo with all current group IDs in, then user can select one
	  or type in a new one easily.

	- Style names - allow multiple widgets to use the same style - not
	  quite working yet - need to propagate style when widget created.

	- Add InputDialog as another item on the project toolbar?
	- Add Font dialog to the project toolbar (it should be in GTK by the
	  time we're ready).

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

	- Background color - when a window is selected the bg color shows
	  through labels - I think its supposed to! - but it doesn't always.
	- Change border width - bg pixmap of parent not displayed properly -
	  editor_refresh_widget() paints a solid rectangle.

	- (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.

These aren't so important:

	- use imlib to allow 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).
	- Should select on button_release rather than button_press? - allows
	  dragging/resizing when multiple widgets selected.
	- Buttons/Items that aren't using labels don't 'prelight' properly -
	  might be because several widgets don't draw the background,
	  including the holding widget event boxes - not really our fault.
	- ScrolledWindow - do we need properties for the scrollbar adjustments?
	  Or are they automatically determined by its children?
	- 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?
	- 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
	- Minor memory leaks in windows/dialogs - the wmname & wmclass strings
	  in the object data hash should be freed when the widget is destroyed.

	- Help files - if we use Gnome we've got the HTML widget.
	  manual.txt containes a few notes. Also need to describe how to add
	  custom widgets, when that works. + few example programs.

Damon, 4th June 1998