A Blue Sky GNOME 2.0 development platform

Here is my personal "Blue Sky" situation for the GNOME 2.0 development platform. I realize that it might be too ideal and we might not be able to pull this off if other factors affect the schedule.

First I bring up a few considerations that can be useful for deciding how we want to move forward, and then a proposed plan for gnome-libs

1. A few considerations

1.3 Bonobo

With the arrival of Glib 2.0 and Gtk 2.0, Bonobo can stop depending on Gtk+ so it would make sense to make the non-GUI parts of Bonobo depend only on glib and not in anything else.

The GUI part of Bonobo could be hence included into Gnome Libs or it could be available as a separate package.

We want to see Bonobo used in more projects, and we might produce a C++ based version of the core Bonobo.

1.4 Printing

Adding printing to the gnome-libs might be too hard of a task and adding the entire gnome-print on top of it might not be a great idea (just my gut feeling).

But printing is still important, so I would like to see an abstract class/API to be exposed at the gnome-libs level.

The idea would be to have the GnomePrintContext opaque data type and a set of externs that we could plug into.

1.5 Small issues

The setup for macros in gnome-libs is still sub-optmial (the dependency on gnome-common is not ideal, and it could be effectively done correctly by just following the model used by other modules (Gtk+, OAF, GConf)).

2. Gnome Libs changes proposal

In a blue-sky scenario, I would like to see gnome-libs shape like this:

  • libgnome: The existing libgnome.
  • liboaf: The OAF library only.
  • gconf: The configuration engine (which honestly should be replaced with something that supports something like CORBA_Any as I expressed before).
  • libgnomevfs: The GNOME VFS engine.
  • bonobo: The core non-GUI parts of Bonobo.
  • bonobo-conf: The moniker code that wraps GConf and can be used to replace GConf. We can use Colm's work to replace GConf.
  • libart: The existing libart.
  • libgnomeui: The current libgnomeui with any adaptations required for properly supporting Gtk+ 2.0.
  • bonobo-ui: The UI bits of Bonobo that depend on Gtk+/libgnomeui.
  • libzvt: The current libzvt.
  • libgnomecompat: As much possible compatibility code as possible to achieve humanly possible source compatibility with the GNOME 1.2 platform.

There are problems for this setup, as this would tie some of the technologies to Gtk+ and Gnome-Libs and it might not fly with everyone the integration of technologies. So we might end up with something like this:

A set of dependencies for gnome-libs:

  • OAF + liboaf: The complete OAF module which is independent of GNOME.
  • GConf: The current GConf in its current state.
  • BonoboCore: The non GUI parts of Bonobo which only depend on OAF + liboaf.

Gnome Libs would then look like this:

  • libgnome: The existing libgnome.
  • libgnomevfs: The GNOME VFS engine.
  • bonobo-conf: The moniker code that wraps GConf and can be used to replace GConf. We can use Colm's work to replace GConf.
  • libart: The existing libart.
  • libgnomeui: The current libgnomeui with any adaptations required for properly supporting Gtk+ 2.0.
  • bonobo-ui: The UI bits of Bonobo that depend on Gtk+/libgnomeui.
  • libzvt: The current libzvt.
  • libgnomecompat: As much possible compatibility code as possible to achieve humanly possible source compatibility with the GNOME 1.2 platform.

And there might be some small variations on the above (like better integration of the menu/toolbar API with the bonobo toolbar/menu API, maybe replacing the existing gnome-app-helper code).