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

[Havoc Pennington <hp redhat com>]

Martin Baulig <martin home-of-linux org> writes:
> 
> first of all, would it be possible for me to attend the next such meeting
> if there's ever one ? After doing a lot of work in gnome-libs HEAD in the
> last few month, I just have a strong feeling that I should be there.

This meeting wasn't very technical in nature or discussing specific
technical issues, it was just a high-level overview type of thing. I
have a sense that we need to have a technical conversation among the
various library maintainers to figure out what's going on for GNOME 2
with libgnomeui, gtk, GAL, nautilus-extensions, etc. Jody suggested
this for GUADEC IIRC. Though we may need to make some decisions sooner
than that if possible, I don't know.
> 
> However, it's really nice that the discussion about GNOME 2.0 now finally
> started. Assuming that this is only the start of a discussion, let me
> layout my "vision" of GNOME 2.0 here.

Excellent.

> I.) gnome-libs - the Development Platform

OK, let me disagree right away ;-) The devel platform is really a
whole set of libs, such as gconf, Bonobo, libxml, gtk, libart, popt,
etc.

I think we should keep it that way, nice and modular, for reasons
outlined in the separate mail I just posted. Also, if you look at the
platform this way, quite a lot of development has been going on over
the past year: gconf, bonobo, libxml2, gtk2, etc. - so we really have
been working on the devel platform quite a bit.
 
> So I think it is very essential to make gnome-libs as good and as polished
> as ever possible. When people now say that we won't have much time to work
> on gnome-libs, this makes me feel a little bit like it was my fault since
> I could have done more work on it and because I could have attracted more
> other people to hack on it in the last few months. If I remember correctly,
> our goal was to work on gnome-libs between GNOME 1.2 and 1.4, but this just
> didn't happen.

We can have time to work on gnome-libs, but only by sacrificing either
the work on the end user environment, or sacrificing the release
date. I don't see much way around that. I think we have to pick two of
"release date", "user environment", and "gnome-libs." Specifying all
three in the release goals makes the release goals meaningless,
because all three simply will not happen.

While I expect the way to hurt the least people's feelings and
minimize flames would be to drop the release date, I also think that
would be the worst option for GNOME and for free software operating
systems as a whole. So I'd personally prefer that we make the hard
decision.

> a) Deprecated things
> --------------------
> 
> Currently, there are a lot of things in gnome-libs stable which have been
> deprecated in HEAD. And if you have a closer look at gnome-libs stable, you'll
> find out that some of this stuff was already deprecated and only half-finished
> in gnome-libs 1.0.x. 

Unfortunately, some of this such as gnome-stock is not only
deprecated, it's also sort of randomly rearranged. I personally
screwed up gnome-stock for example.

I really think that both deprecating _and_ breaking an API is
terrible. If people flamed us for that they would be 100% correct. So
we need to address this issue, perhaps by backing out some of the
changes to deprecated APIs.

> Another problem is that gnome-libs 1.0.x has been misused
> as a dumping ground for some random cruft just because people found no other
> place to put it.

Right. Which is why we need to be sure that a) gnome-libs has a clear
functional definition and b) there are other places to put
experimental or unfinished things. But so far, a lot of the stuff
added to gnome-libs HEAD is just as unfinished as the pre-1.0 stuff in
gnome-libs, and lots of the pre-1.0 stuff still isn't finished.

I think cleaning up what's there, making sure it's nice and backward
compatible, etc. will already be a couple months of work. So that's
late April. If you freeze then, then you have only 6 months left to do
the user environment; and you need 2 months at the end of that for
freeze also; so basically there isn't time to add features to
gnome-libs while also releasing this year and having a few months to
do user environment. 
 
Frankly we don't have many people to work on this, either. I'd kind of
hope that George, you, Iain, etc. would be helping out with
gnome-core, gnome-utils, help browser, that kind of thing - I think
that'd be more valuable than spending too much time on gnome-libs.
Though we do need someone making gnome-libs their primary focus for
the next couple of months just to get it cleaned up and stabilized,
even if no new features go in there.

> I think it is clear that things which have already been deprecated,
> half-finished or even not at all useful back in gnome-libs 1.0 must go away
> for gnome-libs 2.x.
> 
> In the last few months, I have already removed a lot of such stuff, but we
> must have a closer look at all the stuff in gnome-libs.

Simply removing isn't such a good idea. It should instead get marked
with macros as we did for GTK, as you mention below. Most apps compile
nearly unchanged with GTK 2; we did introduce a bit more breakage for
custom widgets, but pure application code is not very broken. It seems
to me that libgnomeui currently breaks a lot more application code
than GTK 2, and this could be a big problem. Miguel warned us about
this over a year ago, and he was right.
 
> To avoid too much breakage to existing applications, we should discuss whether
> we want to have some kind of compatibility layer which will allow GNOME 1.x
> applications to use the new gnome-libs with minimal changes.

I believe that writing a "compat lib" is too much work and won't
happen. The way to do it is to just leave the features in the main
lib, and just don't touch them. Add the DISABLE_DEPRECATED macro as
with GTK 2. Or move them to a compat lib, but don't change them at all
in the process. But you get problems with circular dependencies and
such.
 
> c) GtkArg -> GParam
> -------------------
> 
> This is probably one of the largest breakages in gnome-libs which could have
> been at least particially avoided if the GTK+ folks didn't remove the GtkArg
> compatibility code.

As Tim says, I don't think we removed it. Lots of GTK widgets still
use the gtk_arg_ API.

> d) GConf integration
> --------------------
> 
> Well, maybe someone who's more familar with GConf than me should comment
> on this issue.

The main thing would be to use GConf for any UI preferences, replacing
gnome-preferences. I don't think there's much other reason to
integrate with GConf.

Note that one of the last minute features still to be crammed into GTK
2 is a bunch of UI prefs, such as double click time, and these will be
GConf-integrated and also integrated with KDE via a set of weird hacks
you don't want to know about.

> e) Error handling
> -----------------
> 
> RFC: In gdk-pixbuf and other libraries, there are functions which take a
>      GError argument for error handling. When these functions are called
>      inside gnome-libs, the caller normally does the error handling (by
>      means of g_warning etc.).
> 
>      Should there be a way to pass down a GError argument to gnome-libs
>      functions ?

GError should be used whenever you might want to know the exact error
that occurred or have an error message to display to the user.
 
> RFC 1: Please look at gnome-selector.[ch], gnome-file-selector.[ch],
>        gnome-entry.[ch] and gnome-icon-selector.[ch] and tell me what you
>        think.

I have quite a few comments on this I need to send you.

The general comment I would have though is that I think this is a
large project. I think it will take several months to finish, and I
think it should potentially integrate with Nautilus or use some of the
Nautilus features. I'm basing my time estimate on the fact that
currently Nautilus is frozen and its hackers are busy, and also the
time that it took to implement the various widgets and features in GTK
2. Also, we've given quite a bit of thought to a new file selector for
GTK and feel that this would be a substantial amount of work.

So, my suggestion would be that it's not a good idea to try to rush
this in to GNOME 2. We could do it as a separate lib, give it time to
be really nice, and put it in GNOME 2.2, much as GNOME 1.2 added
gdk-pixbuf. For key user-visible selectors, such as in the panel, if
you stabilized by say August or September you could still have the
panel using it for GNOME 2 even. But it's better to have that
instability in a separate module in the interim, rather than in
gnome-libs.
 
> g) Bonobo integration
> ---------------------
>
> Well, basically I'm still waiting for Miguel to tell me how to do
> this ...

I don't think you want a bullet point for "bonobo integration" or
"gconf integration" or "VFS integration." Just use those libraries
when they make sense, rather than trying to think of uses for them.

As I said in my other mail, I don't think Bonobo etc. should go in the
gnome-libs tarball. I think we need more modularity and division of
maintainer labor, not less.
 
> In the last few months, several cool and nice things have been developed
> in GNOME. We should have a look around at all these nice things and discuss
> whether we should move some of this stuff into gnome-libs. Especially in
> libnautilus and libnautilus-extensions there seems to be such stuff.
> 
> For instance, what I'd like to see in libgnomeui is:
> 
> - this nice icon list / icon canvas item stuff
> - maybe some stuff from gal
> 

Certainly this kind of thing would be a multi-month project. I think
most of the interesting widgets are individually multi-week or
multi-month projects to productize them.

Havoc

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers