Re: GNOME 2.0 Status and Martin's Travelling Schedule

[jrb redhat com]

Martin Baulig <martin home-of-linux org> writes:

> [This mail is cross-posted to a lot of mailing lists, please
>  keep followups on gnome-2-0-list]
> 
>     May 04-06 - Braunschweiger LinuxTage, maybe we have a
>         network connection at the booth, maybe not ....
>     May 07th - Holidays in Hamburg :-)
>     May 08th-10th - University :-(
>     May 11th-13th - Holidays in Dortmund :-)
>     May 15th-17th - University :-(
>     Jun 06th-07th - Madonna concert in Cologne :-)

Whee!  The high's and lows of Martin's life!

> * You cannot install GNOME 1.x and GNOME 2.x into the same $(prefix)
>   without breaking your GNOME 1.x installation at the moment.
> 
>   Someone needs to look at this to allow a clean parallel install of
>   both platforms.
> 
>   Jacob showed interest but was not sure whether he has time to do this.

This should be done in the same way as gtk+/glib/pango are done.  I
don't think it'll take a lot of work to do so -- I could take a crack at
it this weekend if noone else beats me to it.

> * The whole GnomeSelector story in libgnomeui is a complete mess at the moment.
> 
>   GnomeSelector is basically somethink like "my baby" for me, but if you want
>   to hack on it and give it some loving, here's what needs to be done.
> 
>   This weekend, I splitted the GnomeSelector API into a CORBA interface which
>   is in libgnome and the UI which is in libgnomeui. The idea behind this is as
>   follows:
> 
>   GNOME::Selector is a CORBA interface which provides all the non-UI
>   functionality of a selector widget. The first step is to find a solution to
>   this async callback problem (we don't really need a multi-threaded ORB for
>   it to work, we just need to define an API for the async stuff).
> 
>   If you look at libgnome/gnome-selector.h, you'll find the following functions:
> 
>        gnome_selector_check_filename            gnome_selector_check_directory
>        gnome_selector_add_file                  gnome_selector_add_directory
>        gnome_selector_add_uri                   gnome_selector_get_uri_list
>        gnome_selector_add_uri_list              gnome_selector_get_uri
>        gnome_selector_set_uri                   gnome_selector_clear
>        gnome_selector_update_uri_list           gnome_selector_get_history_id
>        gnome_selector_set_history_id            gnome_selector_get_history_length
>        gnome_selector_set_history_length        gnome_selector_prepend_history
>        gnome_selector_append_history            gnome_selector_get_history
>        gnome_selector_set_history               gnome_selector_load_history
>        gnome_selector_save_history              gnome_selector_clear_history
> 
>   For each of these functions, add a corresponding method to GNOME::Selector
>   (remember to use studlyCaps - which means names like `checkFileName()' etc. -
>    in the IDL to make it consistent with Bonobo).
> 
>   Then move all these function to libgnomeui/gnome-selector-client.c, rename
>   them to gnome_selector_client_*() and make them talk to the GNOME::Selector
>   CORBA Object.
> 
>   The GnomeSelector API is new in GNOME 2.0, so you can change it to find a good
>   solution for that async callback problem.
> 
>   When you're done with this, remove libgnomeui/gnome-selector.[ch] and
>   libgnomeui/gnome-file-selector.[ch], but put back libgnomeui/gnome-file-entry.[ch]
>   (you can use libgnomeui/gnome-entry.[ch] as a starting point).
> 
>   Then look at GnomeEntry, this is an example on how you can do the other widgets.
> 
>   What needs to be done are GnomeFileEntry, GnomeIconEntry, GnomeIconSelector and
>   maybe GnomeNumberEntry (put it back from libcompat).
> 
>   My idea is to have one function
> 
>      GtkWidget *gnome_entry_new (const gchar *history_id);
> 
>   which should match the one that's used in GNOME 1.x if at all possible.
> 
>   This function creates a new GnomeSelector (for GnomeEntry and GnomeNumberEntry) /
>   GnomeFileSelector (for all the others) BonoboObject - make sure to transform all the
>   the virtual methods overrides from the GnomeSelectorClientClass (do_add_uri_cb etc.)
>   into g_signal_connect's - which will provide all the non-UI functionality.
> 
>   Then create your UI, bonobo_control_new() it and call gnome_selector_bind_to_control().

Woah!  Are you proposing mirroring every widget in libgnomeui as a
bonobo control or something?  That sounds like a huge amount of bloat
for very little gain?  What's wrong with just using widgets here??

> * GnomeMDI - broken and not compiled into -lgnomeui at the moment
> 
>   This is basically a weekend hacking job, but a very complicated one, so you shouldn't waste
>   your time even trying to do it if you're not familar with the Bonobo UI API (btw. the API is
>   the same like the one in GNOME 1.x).
> 
>   The TODO item is only two words: "Bonoboize it !"
> 
>   What you need to do is to make it use the Bonobo UI API instead of the deprecated GnomeUIInfo.

Why?!?!??  Why are we bonoboizing stuff in libgnomeui?  I'm confused
here.  I don't think our widgets are complicated enough, and our
component system light-weight enough for us to consider this.

> * Move the stock icons from libgnomeui/pixmaps into GTK+
> 
>   If you want to do this, have a look at libgnomeui/gnome-stock-icons.[ch], this is already the
>   code which you can use in GTK+.
> 
>   This is an easy job, all that needs to be done is communicating with the GTK+ folks and having
>   someone who does the CVS move.

http://bugzilla.gnome.org/show_bug.cgi?id=50280

> * I already removed most of the deprecated stuff from libgnomeui (it's now in libcompat/libgnomeui).
> 
>   For someone who's familar with GTK+:
> 
>   - walk over all files which are left in libgnomeui and find out whether GTK+ 2.0 provides a
>     similar or even a better feature

A very quick look reveals:

gnome-animator.h -> replaced by GtkImage
gnome-geometry.h -> working in gtk
gnome-less.h -> pretty silly anyway
gnome-pixmap.h -> replaced by GtkImage
gnome-stock* -> replaced

I can have a longer look this weekend.

> * Disabled stuff:
> 
>   If you look at libgnomeui/ChangeLog and libgnomeui/Makefile.am, you'll find that there are a couple
>   of files in libgnomeui which aren't compiled into -lgnomeui at the moment.
> 
>   It's best to just look at libgnomeui/Makefile.am, I put all of them into `unused_SOURCES'.
> 
>   I disabled it because it was either using stuff which I wanted to move to libcompat (for instance
>   gnome-app-helper) or because I had no idea about what it is and whether it is useful.
> 
>   Here's the current list:
> 
>      gnome-popup-menu.c
>      gnome-popup-help.c
>      gnome-helpsys.c
>      gnome-textfu.c
>      wap-textfu.c
> 
>   For gnome-popup-menu.[ch] and gnome-popup-help.[ch], there may be a similar or even the same in
>   libbonoboui, but I haven't looked yet.
>
> * gnome-helpsys.c, gnome-textfu.c, wap-textfu.c
> 
>   Elliot, what's up with these files, you put them into libgnomeui last century and then never looked
>   at them again ?
> 
>   I'd consider this API at least as "highly critical" at the moment; it's immature, half-finished and
>   nobody seems to care about it.

{wap,gnome}-textfu should be tossed and replaced with the pango-markup
system; a GtkLabel will now do most of that functionality now.
gnome-popup-help/gnome-helpsys/gnome-help-whatever needs some serious
emergency work for 2.0.  I think a lot of our efforts need to go into
making a good help system.

I don't know what we're going to do about the menu API, but I think
leaving it as is is probably the best solution as we don't have time to
rewrite it for this release.

Thanks,
-Jonathan