Re: GNOME 2.0 planning: A longer range roadmap
- From: Maciej Stachowiak <mjs eazel com>
- To: George <jirka 5z com>
- Cc: gnome-hackers gnome org
- Subject: Re: GNOME 2.0 planning: A longer range roadmap
- Date: 20 Feb 2001 13:59:47 -0800
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]