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

[Martin Baulig <martin home-of-linux org>]

Hi,

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.

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.

I.) gnome-libs - the Development Platform
=========================================

As you all know, gnome-libs has been frozen for such a long time that I
even forgot whether it was in 1998 or in 1999. During this time, there
was no improvement to gnome-libs at all while there were a lot of other
new and cool libraries such as gconf, gnome-vfs, bonobo etc. added to
the development platform.

With this background, I think it's safe to assume that gnome-libs 2.0 will
stay frozen for at least another two years. Within these two years, we'll
hopefully get a lot of new contributors which will all start to use the
new library.

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.

However, let's stay constructive and so I'll concretize my plans and ideas
for gnome-libs a bit more in detail:

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. 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.

We must avoid doing this same mistake again for gnome-libs 2.0. In g-l 2 there
should be only things which are generally useful, fully functional, completely
documented and well tested.

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.

b) Compatibility layer
----------------------

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 think after GNOME 1.4, we should add some things to the stable version of
gnome-libs to ease migration to gnome-libs 2.x for application developers:

i) There should be a #define to disable all deprecated stuff.

   For instance, we can #ifndef GNOME_EXCLUDE_DEPRECATED all such function
   prototypes, typedefs etc. in the header files.

   This won't break binary compatibility, but it'd allow application developers
   to pass -DGNOME_EXCLUDE_DEPRECATED when compiling their applications to make
   sure they aren't using this stuff anymore.

ii) There are things which have been renamed in gnome-libs HEAD or replaced
    by something better.

    A prominent example for this is GtkEntry misuse in gnome-libs 1.x. I mean,
    there's code like this:

        GnomeFoo *foo;
        GtkEntry *entry;
        gchar *text;

        foo = get_it_from_somewhere ();
 
        /* we're only interested in text */
        entry = gnome_foo_get_gtk_entry ();
        text = gtk_entry_get_text (entry);

    In gnome-libs 2.x this has been replaced by:

        GnomeFoo *foo;
        gchar *text;

        foo = get_it_from_somewhere ();
        text = gnome_foo_get_text ();

    We can ease migration a lot if we add these new accessor functions to the
    stable gnome-libs and deprecate the direct use of the GtkEntry.

If we do this, we don't "loose" so much time while we're working on the new
gnome-libs since people can already start porting their apps to the new
system while we're still working on it.

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.

d) GConf integration
--------------------

Well, maybe someone who's more familar with GConf than me should comment
on this issue.

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 ?

f) GnomeSelector, Gnome-VFS integration or Martin's Baby
--------------------------------------------------------

First of all, let me explain what GnomeSelector is, what it does and
why it's there.

In gnome-libs 1.x there are widgets like GnomeEntry, GnomeFileEntry,
GnomeIconEntry, GnomeIconSel etc. All of them share some common technology:

- they store/manage a list of directories/files
- they have an UI to let the user browse these lists etc.
- they have history support

If you look at the code of these widgets in gnome-libs 1.x, you'll see that
there's a lot of similar code in all of them since they implement more or
less the same technology.

GnomeSelector is an abstract base class which provides all the common
technology between these widgets. This means that for instance GnomeIconSelector
inherits all of its functionality from GnomeFileSelector which itself inherits
from GnomeSelector. The only thing which GnomeIconSelector needs to implement
is its UI.

GnomeSelector already uses GNOME-VFS and is fully asynchronous.

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.

RFC 2: We can avoid some API breakage if we provide synchronous wrapper function
       for the async functions (some of them return values / error conditions,
       so we'd need to wait until the async operation is completed).

       Do you think it's reasonable to do this or should we directly make
       everything async ?

g) Bonobo integration
---------------------

Well, basically I'm still waiting for Miguel to tell me how to do this ...

h) Other things which I'd like to have integrated in gnome-libs
---------------------------------------------------------------

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

-- 
Martin Baulig
martin gnome org (private)
baulig suse de (work)