Re: GNOME 2.0 planning: A longer range roadmap

[George <jirka 5z com>]

On Sun, Feb 18, 2001 at 10:01:28PM -0500, Havoc Pennington wrote:
> So perhaps this is the time to start getting concrete as you and
> George have requested - what is it you want to do in gnome-libs that's
> beyond just cleaning it up, including moving gnome-config to GConf and
> adapting widgets to VFS in "cleanup"? Any new widgets or APIs? Why
> can't those go in a point release, perhaps starting in an experimental
> lib for GNOME 2 so GNOME itself and hobbyist apps can use them? What
> is it gnome-libs really needs that can't be done by July?
> 
> In a roundabout way, I'm even agreeing with George here that there's
> no black-and-white conflict between doing libgnomeui features and end
> user features. What I'm arguing is simply that new libgnomeui features
> maybe shouldn't go in GNOME 2, they can go in 2.2 if they are
> bin/source compatible or in a separate module, and GNOME 3 otherwise.
> So that's where I put them on the long-term roadmap you posted.
> 
> I think we can end the thread if we agree that anything in gnome-libs
> that's not finished by July has to come out again. And agree that
> there will be no whining when it's removed. ;-)

In a roundabout way we've gotten to a place where all I can say is, yes I
agree.  Anyway, my "vision" for what should be done on gnome-libs didn't
actually include new widgets an features beyond those neccesitated by
adding gnome-vfs, GConf, bonobo support (I suppose bonobo doesn't enter the
picture here as it doesn't interfere).  Why I was arguing for doing devel
platform work rather then app features work was simply because I think doing
just the cleanup of the mess we've done for ourselves in 1.0 will take a fair
bit of time, and likely breaks in the API still, even though new features are
unlikely to get in.

Let's then get specific, so this are specific tasks I can think of right now
that I believe need doing:

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

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.

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

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)

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?  

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

George

-- 
George <jirka 5z com>
   What luck for the rulers that men do not think.
                       -- Adolf Hitler