Re: GNOME 2.0 planning: A longer range roadmap

[Maciej Stachowiak <mjs eazel com>]

George <jirka 5z com> writes:

> On Tue, Feb 20, 2001 at 01:38:06AM -0800, Maciej Stachowiak wrote:
> > Now we all need to sign a contract on that July freeze date in
> > blood. In fact, let's pick a specific day.
> 
> Well as long as it ain't my blood ...
> 
> > > 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?
> 
> It would cut it, but it requires code change.  I would like apps to comstly
> compile out of the box.

Makes sense.

> > 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).
> 
> Again, same reason as above.

We should deprecate the wrapper then, and make the calls not supported
by GtkDialog into no-op stubs. I think that is the only sane way to go.

> Well I don't think we need anything utterly fancy.  What we need is an API
> and "an" implementation.  If the API is good we can replace it with a fancy
> file selector later.  But I think this is "an emergency" as havoc puts these
> things (and has been for a while).  I think we can do a decent one with a
> good API by july, and have a good bin compat replacement/enhancement for 2.2
> which would be our goal for a good file selector.  I mean if we get the API
> right, then it doesn't matter that the fileselector is not the greatest as
> it can be incrementally worked on throughout the release cycle.

I think this is a sound plan, but I think your suggestion is entirely
compatible with doing the file selector in a separate module. We can
make that module part of the platform in July if it is ready, or wait
for 2.0.1 or 2.2 if not; this is better than starting in gnome-libs
and maybe having to back it out. Once it is truly ready for prime
time, we can consider merging it into gnome-libs.

> 
> Well, AFAIK the patchsets in gnome-libs HEAD should make things work, most
> definately for glib2, dunno if we still use libxml1 in HEAD, could be ...
> 
> Anyway, GConf IS actually used in gnome-libs HEAD so this is not a problem.
> 

I think the main things are to cut a branch of ORBit that works with
glib2, and for me to merge the stable branch to OAF HEAD and apply the
patch from gnome-libs HEAD.

 - Maciej