GNOME 2.0 Status and Martin's Travelling Schedule

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

[This mail is cross-posted to a lot of mailing lists, please
 keep followups on gnome-2-0-list]

Hi guys,

the contents of this mail can be found in GNOME CVS in
gnome-2-plan/gnome-2-status.txt, I'll try hard to maintain
the copy in CVS and keep it up to date.

First of all, I'll be away from most GNOME hackings until
May 18th, so if you're trying to reach me in IRC, here's
my traveling schedule:

    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 :-)

I think there are also a few parties at the university, so
basically the first half of May has been eaten up by traveling,
parties and university stuff ....

So here's the good news:

Currently, the GNOME 2.0 platform compiles and "mostly works" :-)

Status of the "non-GNOME dependencies" and outstanding issues:
=============================================================

This stuff should compile and work without problems.

* ORBit2 - Elliot Lee needs to hack on it and make it work.

      For the moment, forget about it unless you want to
      actually hack on it, you can neither compile nor use
      any of the GNOME 2.0 modules with it, use ORBit-martin-forked
      for the moment.

* oaf - Maciej needs to merge some stuff from the stable branch,
        especially the .oafinfo -> .oaf filename renaming.

Status of the GNOME 2.0 modules:
===============================

It "basically works", at least in a way that you can compile it,
hack on it. If a particular module is not mentioned in this list,
then I don't know of any problems in it. 

* bonobo-conf - Dietmar is working on porting this to GNOME 2.0 and
      splitting it up into a non-X and UI part, parts of it may be
      moved into libbonobo.

* libbonobo - Should compile and run without problems; if there are
      any, Michael Meeks is the right person to ask.

* libgnome - Should compiles and basically run, but it has a run-time
      dependency on bonobo-conf, so Dietmar needs to finish his
      bonobo-conf stuff first.

* libgnomeui - This is a bit messed up at the moment, but stuff which
      is compiled into -lgnomeui should compile and link without
      undefined symbols and maybe even run without producing a core.

Larger outstanding issues aka "Issues which ``block'' the platform":
===================================================================

* Dietmar needs to finish the GNOME 2.0 port of bonobo-conf, he's
  already working on it.

* Bonobo controls only work in-proc at the moment; the help debugging
  download all files in http://cip.uni-trier.de/baulig/misc/bonobo/
  (make them replace the ones in libbonoboui/bonobo), then compile
  everything and look at libgnomeui/demos/selector_demo.

  This tries to embed a BonoboControl in another process; someone who's
  familar with the new GtkPlug / socket needs to have a look at it and
  debug it.

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

* We need a multi-threaded ORB and an easy API to do asnyc operations
  over CORBA.

  I run into this problem when trying to fix GnomeSelector; imagine you
  have an application which is displaying an icon entry. Internally,
  this icon entry is implemented as BonoboControl and it can talk to
  a remove GNOME::Selector CORBA object.

  So if your wants to tell the icon entry to display an image, it calls
  gnome_selector_client_add_uri() which should have the same API like
  gnome_selector_add_uri() in the non-Bonoboified selector:

     void
     gnome_selector_add_uri (GnomeSelector             *selector,
                             GnomeSelectorAsyncHandle **async_handle_return,
                             const gchar               *filename,
                             gint                       position,
                             guint                      list_id,
                             GnomeSelectorAsyncFunc     async_func,
                             gpointer                   user_data);

  Now imaging this function is called gnome_selector_client_add_uri() and
  it invokes the `add_uri' method on a remote GNOME::Selector CORBA object.
  This operation must not block until the image is loaded, but return
  immediately and trigger a callback when the image is loaded.

  Any feedback on this topic is greatly appreciated :-)

* 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().

  [Oh, almost forgot an important WARNING:

   It's already too late in the night to fix this, but the type of the second argument of
   gnome_selector_bind_control() was a very bad idea:

        void
        gnome_selector_bind_to_control (GnomeSelector *selector,
                                        Bonobo_Control corba_control);

   This needs to be changed into

        void
        gnome_selector_bind_to_control (GnomeSelector *selector,
                                        BonoboObject  *control);

   to make it clear that it only accepts a newly created, local BonoboControl.
  ]

  After that, you have a working GNOME::Selector CORBA Object :-)

  Now, you can add a new function

        GtkWidget *
        gnome_entry_new_from_selector (GNOME_Selector      corba_selector,
                                       Bonobo_UIContainer  uic);

  which constructs the GnomeEntry from a remote GNOME::Selector and pass your newly
  created GNOME::Selector CORBA Object from your gnome_entry_new() to this function.

  That's basically the easy part of GnomeSelector so far - oh, it almost takes more
  time to write this than to fix it myself :-)

  Now comes part which is a bit more complicated.
  If you look at libgnomeui/libgnomeui/gnome-selector.c you'll realize that the "old"
  (pre-Bonobo) GnomeSelector API contains three construction properties "browse_dialog",
  "selector_widget" and "entry_widget".

  The plan is to make these properties moniker strings.

  It's not really that much complicated if you're a bit familar with Bonobo. What you
  need to do is the following:

  - change the type of these properties to G_TYPE_STRING
  - create a new directory libgnomeui/components, move libgnomeui/gnome-icon-selector.[ch]
    into that dir, rename it to gnome-icon-selector-component.[ch] and make it a
    GNOME::Selector.
  - in libgnomeui/gnome-icon-entry.c, don't create an icon selector for the browse dialog,
    but call bonobo_object_get (string_from_the_browse_dialog_property, "Bonobo/Control")
  - do the same in libgnomeui/gnome-icon-selector.c for the selector widget.

  That's it, basically. Oh, and now I spent so much time writing a TODO list for what I want
  to do in GnomeSelector during the next few weeks. But don't worry, there's enough work to do,
  so if you want to work on any of these items, just go ahead :-)

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

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

* 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

  For someone who's familar with Bonobo:

  - walk over all files which are left in libgnomeui and find out whether Bonobo provides a similar
    or even a better feature

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

* Find out whether to move GNOME::Unknown into oaf or not.

  [This paragraph is only here so I won't forget about it, I'm already talking with the relevant people.]

* Make libcompat actually work

  This is one of the easier jobs again, all you need is someone who CVS moves you the files from
  gnome-libs/libcompat.

This is basically all that I can remember at the moment. If there's anything missing, just let me know
and add it here.

May 3rd, 2001
Martin Baulig <baulig suse de>

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

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