Re: GNOME 2.0 planning: A longer range roadmap

[Maciej Stachowiak <mjs eazel com>]

George <jirka 5z com> writes:

> 
> In a roundabout way we've gotten to a place where all I can say is, yes I
> agree. 

Now we all need to sign a contract on that July freeze date in
blood. In fact, let's pick a specific day.

> 
> 1) Figure out what to do with gnome-stock, it's in GTK2 and it's broken in
> g-l HEAD.  We can't just use the old code as that used imlib, and I'm more in
> favour of perhaps doing wrappers that may cover 90% of the cases and wrap
> GTK2

Would using the Gtk2 stuff directly not cut it?

> 2) Figure out what happens to GnomeDialog now that we have a capable
> GtkDialog.  GnomeDialog has actually more accessors then GtkDialog last I've
> seen (as far as I remember, I may be on crack).  That is GtkDialog doesn't
> store it's buttons afaik.  Perhaps writing this as a wrapper around GTK2's
> GtkDialog and the stock icons stuff.  Doesn't have to be perfect, just handle
> again the 90% of cases.  Or maybe just keep the current implementation and
> just use GTK's stock icons.

Actually, GtkDialog now covers the common 90% of GnomeDialog (Havoc
added a few calls for setting default button, etc). There are still a
few calls in GnomeDialog that are covered, but I think those calls are
not really needed anyway. So I think we can pretty much just switch to
GtkDialog (the one thing it probably does not support is the various
options in the User Interface/Dialogs capplet, but IMO that capplet
should die, and as far as I can tell many of those settings are not
respected anyway).

> 3) Figure out a simple way to make GnomeUIInfo wrappable.  Rewrite isn't
> going to happen of this stuff, we just need to make it usable by bindings,
> and we need it to keep compat

There are also the Gtk and Bonobo menu/toolbar APIs. I wish people
would sit down and figure out the One True menu/toolbar API (my dream
would be Gtk-level support that provides enough hooks for bonobo to
make it work cross-component).

> 4) Make sure GnomeSelector has a good API and make sure it's usable (it's
> probably a better API then the rest of gnome-libs to begin with)

I promise to do an API review of this by GUADEC (one thing I am
concerned about is making sure the async stuff is used and exposed in
a proper way).

> 5) A nice gnome-vfs fileselector dialog.  If apps are to use gnome-vfs they
> need a good fileselector as part of the standard libs.  And I think this
> falls under the emergencies heading.  Wasn't there one floating around
> somewhere?  

There are several attempts but none is really usable or at all likely
to be ready to freeze for July. I think this is something that needs
to be started in a separate module (I can see it getting pretty fancy
if we support lots of nautilus features like custom icons,
thumbnailing, etc) and maybe later migrate into gnome-libs.

If we wanted to we could do a crappy one by taking the Gtk one and
just porting it to gnome-vfs, but the result would be super lame and
there is no way I would want to declare that part of the platform.

> In addition to there it's of course getting GParam support everywhere and
> replacing things with GConf, and using gnome-vfs where possible.

These make sense to me.

Something else that might help is starting to port the rest of the
platform to Glib/Gtk/libxml/GNOME 2 sooner rather than later so it's
easier to test stuff. Right now I don't think you could use GConf in
gnome-libs even if you wanted to because ORBit and oaf do not support
glib2 and libxml2 out of the box.

We should also consider starting work on porting at least one desktop
module as a sort of sanity check.

 - Maciej