Re: My vision of gnome-libs (was Re: GNOME 2.0 meeting summary)

[Havoc Pennington <hp redhat com>]

George <jirka 5z com> writes:  
> Well, I don't agree completely.  While adding new widgets after now may not
> be the best of ideas.  A full freeze would be just as stupid.  Cleaning up
> the current stuff in HEAD is likely to result in a few breakages and some API
> changes.  So Yes I do advocate not rewriting any widgets, or anything like
> that from now on.  So I think a Slush should be more like it.

Sure, I don't think we disagree. Cleanup is fine. I don't think there
should be new features, and some unfinished features such as textfu
should come out.
 
> Well, there is a problem with this argument as well.  A LOT of issues in
> core/nautilus/whatever HAS been caused by breakage in gnome-libs.  And many
> usability issues are related to standard widgets.  I mean you cannot improve
> the user interface if you still have the old crappy widgets from
> gnome-libs.

<pedantic>You could simply not use those widgets. ;-) </pedantic>

Though I don't think that's entirely a silly thing to say. If a widget
needs a full rewrite and is totally broken, why are you using it?
Put a replacement someplace and use that. There's not a rule that to
use a widget it must be in libgnomeui.
 
> I really disagree with this.  We simply cannot have gnome-vfs integration in
> apps if we don't have such support in the selector widgets.  This IS a user
> interface issue, not just a development issue.

If they are fine but need VFS support, then OK let's just put in the
VFS support quickly, should be considered a cleanup. If they need a
big rewrite, just leave the old ones alone and do GnomeSelector and
subclasses as a separate thing and don't break apps using the old
ones. i.e. do the GtkList/GtkCList/GtkTreeView thing. If you think
CList is bad imagine it implemented on top of GtkList. ;-)

Then at that point, you have to seriously consider whether it needs to
be in libgnomeui with any urgency, it could be a separate module or
added later. We could do an "add interfaces only" bin/source compat
libgnomeui release in Summer 2002, we're considering a GTK 2.2 release
like that to add maybe a menu API, file selector, and multidisplay
support. While waiting for that release the core desktop apps could
even use an experimental version in a separate module.

But, let's not get stuck on GnomeSelector; if that's the only feature
that goes in we're doing pretty good. I just don't want to see more,
personally. And I don't see the point of bundling the deadline for new
gnome-libs features and the deadline for user apps; let's keep them
separate. If new features aren't ready for GNOME 2 at the end of the
year, add them later. However this does require sort of keeping new
features out of libgnomeui until they are definitely ready, and it
does require freezing the already-existing bits of libgnomeui fairly
early because apps already depend on them.

Anyhow, as I said in that other mail, why create a conflict between
getting the apps out and doing a good job with the new library
features? Let's just avoid the whole issue and merge library features
into point releases as the library features become ready.

(But note, we do need to be sure we don't add new interfaces with
every bugfix tarball of libgnomeui, the major versions should be
forward and backward compatible. So you'd take libgnomeui to 2.2 and
be sure to go through a beta cycle process if you added some widgets,
you wouldn't just drop in the widgets and "make distcheck" and put it
in the stable tree on the ftp site.)

Havoc