Re: Bonobo / Gtk Menu / Toolbars...

[Havoc Pennington <hp redhat com>]

Michael Meeks <michael ximian com> writes: 
>         I only learned of your plans having implemented the first pass at
> the new UI code, either way - we badly needed this for GNOME, and even if
> the current solution is re-written in Gtk+ I believe we can have a good go
> at supporting the API. Also, as yet there is no new Gtk+ menu / dock /
> toolbar API :-)
> 
>         Are there plans to write GtkDock as well ? and in this age of
> planning 17 versions in advance, is there a blue-sky document somewhere
> discussing what you want to do in Gtk+ in the future ? - I hear lots of
> exciting rumours :-)

We haven't written it - the short summary of major directions in
post-GTK2 I know we've discussed, some may never happen, some may only
happen after a long time:

 - menu/toolbar/dock/accelerators/etc. problem

 - file selector rework

 - combo box / option menu something-or-other replacement widget

 - a few other random widgets such as an icon list

 - a vector graphics API similar to Java 2D (I hear some Open2D rumor,
   that would be nice)

 - a canvas widget and printing feature making use of the above

 - move widget system to the vector API; basically this would probably 
   mean having canvas items support a bunch of interfaces shared with 
   GtkWidget, and over a couple releases perhaps converting all
   widgets into canvas items, and eventually you could write a whole
   app that was a big canvas. So in the end you have a fully 
   vector-based widget kit. The advantage is prettier widgets, and 
   also you avoid the current issue that widget-based functionality 
   such as drag-and-drop or selections or keybindings don't work 
   properly with canvas items. Also you can mix-and-match widget-like 
   things and drawing-object-like things, though this is not 
   all that useful in general.

 - moving GTK to be component-based, or supporting an official set of 
   components that wrap GTK widgets, thus obsoleting the 
   hand-written language bindings. APIs would have to be adapted 
   to be usable via a component interface, e.g. lots of the 
   signal-based APIs don't work in this context.

 - ongoing small enhancements, of course

But, this discussion hasn't really been had, these are just ideas I've
heard mentioned. We are sort of hoping to finish GTK 2 before we get
too excited about planning GTK 3. ;-)

There may or may not be a GTK 2.2 which only adds some of the widgets
mentioned above, but doesn't break anything. Undecided. The most
pressing add-on is probably the menu API, but at the same time that
one is pretty hard to do while maintaining bin/source compat unless
you ignore some of the issues.

Havoc