Re: more gnome 2 proposal

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

Miguel de Icaza <miguel ximian com> writes:

> But we can live with the library split, as proposed, and we can live
> with a gnome-libs based on the current work in HEAD.  I would like to
> see something better for GNOME, but I do not want to get involved in a
> multi-week mailing list fight with a coallition.

Hi Miguel,

let's not call this a fight, let's call this a discussion :-)

> Maybe I had not mentioned this before, but we have established a team
> of hackers at Ximian called the "Ximian Labs" (yes, a ripoff from the
> RHAD labs name -- imitation is the sincerest form of flattering ;-)
> who are devoted solely to improving the GNOME platform.  We believe
> that it's important to make Bonobo and other core GNOME technologies
> as high quality as possible, because our success relies on the success
> of GNOME.  The people in this team are Michael Meeks, Jacob Berkman,
> Dietmar Maurer, Paolo Molnaro and Lauris Kaplinski.

This is really a great news, we definitely need this extra portion of
manpower to make GNOME 2.0.

> Our original intention was to have this team devote its time to
> working on GNOME 2.0, to be sure that 2.0 comes out soon and kicks ome
> major butt.  Much of our expertise here is in Bonobo, so naturally we
> were going to focus a lot of our energies on that.
> 
> Your proposal does not seem to realize the importance of having a
> component technology at the core of the system, nor that a unified set
> of libraries would ease a lot of the cross-dependencies and the fact
> that many times we are just plain blocked from using functionality in
> another module because of the dependencies we have.  I understand that
> you and Owen want to build a new component system, and hence
> integrating Bonobo would be a step in the wrong direction for you.

While writing our proposal we were merely looking at what we have now
where we want to go for GNOME 2.0. I mean, we have GNOME 1.4 now and we
just don't have the time to completely rewrite all of gnome-libs - I
don't know what you and Jacob mean with integrating gnome-libs and Bonobo,
but for this sounds like a complete rewrite.

Basically, I had the following scenario in mind with my tarballs:

* libbonobo-2

  This will be the lowest level library and not depend on any other of the
  GNOME libraries. It contains all the non-UI stuff in Bonobo. This code
  currently does not depend on libgnome-2 (except that two header files,
  but that's trivial to fix) and keeping it this way means that libgnome-2
  (and thus every GNOME application) can already use the component system.

* libgnome-2

  This will depend on libbonobo-2, initialize the component system etc.
  Currently, there is not much stuff in this library since a lot of things
  have been deprecated

	gnome-config.c gnome-ditem.c gnome-exec.c gnome-fileconvert.c
	gnome-i18n.c gnome-regex.c gnome-remote.c gnome-score.c
	gnome-triggers.c gnome-url.c gnome-util.c gnome-paper.c
	gnomelib-init.c gnomelib-init2.c

  It may actually make sense to merge libgnome-2 and libbonobo-2.

* libgnomecanvas-2

  The GNOME Canvas as its own module.
  I think having the Canvas in its own module has two main advantages:

  - it is the right decision for the future; GNOME 2.0 won't be the last
    GNOME release ever and there may be a point where we actually want to
    rewrite the canvas or do larger changes in it.

    Having the canvas in its own module means that it can easily have its
    own release cycle, for instance Federico can make a stable branch in it
    and start hacking on the HEAD whenever he feels like it.

    Since we're now rearranging modules anyways, I think it's a good idea
    to directly move the canvas into its own module.

    I don't think that any major changes in the canvas will happen for
    GNOME 2.0, but having it in its own module will make it a lot easier
    to do so after GNOME 2.0.

  - it allows us to make libgnomeui-2 depend on libbonoboui-2

    But see later.

* libbonoboui-2

  This is all the UI stuff from Bonobo. It currently has a little dependency
  on libgnomeui-2, but it is only using GnomeDock and deprecated stuff which
  will go away anyways.

  It shouldn't be that much work to get rid of this GnomeDock dependency and
  then libbonoboui-2 will only depend on libgnomecanvas-2.

* libgnomeui-2

  This should depend on libbonoboui-2 it at all possible.

  For instance, I could imagine using Bonobo for GnomeSelector:

       The selector widgets have a "Browse" button which launches a dialog
       where you can select a file and stuff. You can either specify this
       dialog at object construction time (with a GtkWidget property) or tell
       it to use a default dialog.

       It would make a lot of sense to have it launch a Bonobo component
       which displays the dialog. So you won't give it a GtkWidget on object
       construction anymore, but an OAF query string and it'll then launch
       that component.

  There are a couple of other places where it may make sense to use Bonobo
  components in libgnomeui-2.

  However, all these changes will be rather small and keep most of the
  current structure or libgnomeui-2.

Both libbonoboui-2 and libgnomeui-2 are rather larger and complex libraries
and I also think that libbonoboui-2 as a component model is much more
fundamental than libgnomeui-2.

So we should keep them two separate libraries.

> My desire to have my team work on gnome-libs-2 was to deliver a nice,
> consistent platform in the two main gnome libraries.  I think that we
> can still do this if we focus our effort solely in Bonobo and
> Gnome-Print and on the "components" kit that was part of the latest
> Jacob's proposal.

Miguel, please don't understand me wrong here. Our alternate proposal does
not mean that we want to do our own thing and that we don't want a Ximian
team participating.

Whatever we do for GNOME 2.0, I think it is very, very important to have a
team which is working on making GNOME 2.0 as a whole a success. And of course
it'd be great to have your Ximian hacker group in that team.

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