libgnome* status

[Anders Carlsson <andersca gnu org>]

Here is a current status of libgnome* as maintained by me.  This work is
in the branch called foo-branch of both libgnome and libgnomeui.
vicious-build-scripts are set up to build from this branch when in the head
environment.

Status (API wise):
==================

Stuff that's basically done (API wise):
---------------------------------------

*  bring back entries, remove selectors non-deprecated
   (done)

*  GnomeApp and friends, bring back non-deprecated
   using bonobo-dock and gtk-dialog
   (basically done)

*  deprecated:  gnome-dialog/messagebox, gnome-propertybox
   (done)

*  deprecated:  gnome-stock id's, not the gnome-stock API itself,
   just a compat mapping from gnome-stock id's to gtk-stock ones
   or some extra libgnomeui ones.
   (done)

*  deprecated:  gnome-pixmap
   (done)

*  punt: gnome-geometry, gnome-winhints, gtkpixmapmenuitem
   (done)

*  bring back gnome-triggers, gnome-sound (non-deprecated)
   (done)

*  bring back gnome-config (non-deprecated, but with a big
   comment explaining when it's appropriate to be used)
   (done, the comment needs to be put in place)

*  bring mostly back gnome-i18n (non-deprecated)
   (done)

*  whack libgnome1-compat and use GNOME_DISABLE_DEPRECATED,
   following the gtk+ scheme
   (done where needed)

Stuff that needs doing:
-----------------------

*  finish gnomedruid stuff, includes API changes (jrb)
   (not a requirement for 2.0, but a would-be-nice)

*  s/bonobo_config/gconf/
   (brought back gnome-gconf, the non-widget stuff)

*  gnome-mdi 1.0, re-port, deprecated (george)

*  help stuff, this would be new API (jrb is working on a proposal)

*  ???: gnome-preferences

*  bring back gnome-score (non-deprecated)

*  finish gnome-about, this would be new API (anders)

Issues and concerns:
--------------------

* gnome-preferences is used in bonoboui.  This is utterly broken, this is a
  stupid and fairly useless API that should be replaced in code by code that
  actually waits for notification and does gui changes and such.  This API
  doesn't allow that.  It was marked to be deprecated in 1999, but somehow
  survived and in fact changed homes to be in libgnome.  This is why it was
  not yet punted.  I'd suggest bonobo stop using this API and do this the
  correct way (get the keys directly, and watch for notification).  And we
  should then put this API out of it's misery.

* gnome-stock:  It has not been brought back completely.  We brought back
  only the stock ID's (which is what vast majority of people are using from
  this API).  The API itself is a lot of code that completely duplicates, in
  a very evil manner.  It duplicates (doesn't use the gtk ones) all the
  pixmaps and states in memory as far as I can see, so it's also a memory
  hog.  The way we did this was to just use gtk-stock stuff.  There already
  was a file in libgnomeui, gnome-stock-icons that adds a bunch of icons that
  aren't in gtk itself.  So we have the same stock icon set that 1.0 has.

API Changes (stuff that's actually changed):
--------------------------------------------

*  In gnome-program we added per application file domains.  Added per app file
   prefixes that an app needs to set if it wants to use the file location
   function for locating files.  This will be needed when looking for HELP
   files.  The APP_HELP domain was broken (as in not doing anything
   desirable) in the HEAD version, now it looks in the right place.

*  Something that Martin actually agreed on was bringing back the HEAD
   versions of the entries and punting the selector stuff for now.  The
   HEAD versions have slightly different API. George also added most of the
   GtkEditable interface to them, so that there is a consistent way of
   accessing them as entries (except the GnomeIconEntry which is not an
   entry)  In any case current usage of GnomeEntry, GnomeFileEntry and
   GnomePixmapEntry should pretty much just compile and work.  IconEntry
   did not in fact work in gnome 1.0 (try pressing the cancel button after
   selecting an icon in the 1.0 version)  And solving this required actual
   API changes.  All of these now have a "changed" signal so getting the
   underlying entry is (except in rare occasions) not needed.

//andersca
andersca gnu org