This file is not a milestone feature checklist, just a list of things
I'd like to do for various releases. It is only a scratch-pad, don't
expect it to make any sense. DO NOT ASSUME THAT IF YOU SEE SOMETHING
HERE, IT WILL ACTUALLY BE IMPLEMENTED FOR THAT RELEASE.
						- Cactus

Next point release (1.2)
========================
    Figure out why resizing forms is ass-slow compared to resizing widgets


Post-1.2
========
    widget grouping (to move them together)

    icons, bitmaps
    formbitmap widgets
    support for graphical buttons, pushbuttons, popup triggers,
	        selector triggers, repeat buttons

    locales

    custom fonts

??? Relative positioning
??? Group resizing
??? In-place editing for texts
    Preview in Dialog Editor

    RCP importing
    
    Migrating to GNOME 2 (depending on the schedule of Guikachu and GNOME 2
	  releases) -- this will likely be post-1.2
??? Anjuta IDE support

from #usability:

<huey_> is there a reason you can't have multiple Properties windows reflecting the state of multiple widgets/
<huey_> ?
<Cactus> technically, no
<huey_> I think this would be very nice, but the titlebar of the Prop. window would have to make clear what widget it is reflecting
<huey_> then I propose not to limit the # of prop. windows, so this is no reason to keep track of last-selected

<huey_> let the resize grip resize whatever widget the mouse cursor is on, but at the moment the dragging starts, remove the visible grips from other widgets so it's clear what is happening
<Cactus> good idea
<huey_> do they pop up automatically? can't I right click on a widget and select 'properties' from the popup menu?

Internal stuff
==============
--- Use Bakery for Doc/View (it might be too late for that...)
    Use GnomeVFS for I/O (maybe this should wait until GNOME 2)
??? XML schema for .guikachu file format (would it be useful at all?)
--- `Components' instead of `Resources' (to not have to make App and Blob special cases)
    Lots of redesigning needed to be able to finally remove the _pre classes which
	are just plain ugly. Properties need to be 'abstract' instead of being actual
	class members in the 'interface classes'.
