Planning GNOME 2.0

Miguel de Icaza
miguel@gnu.org

Ximian, Inc.

This document was a work in progress document. And is outdated now. Please check developer.gnome.org for actual details on the release process.

The GNOME 2.0 schedule was posted to gnome-2-0-list: here

Abstract

This document provides some background on the way we have developed GNOME in the past, the integration work that lies ahead and outlines the problems that we might run into if we are not careful with the goals we set for GNOME 2.0

That being said, a Blue Sky overview of the gnome-libs 2.0 is presented.

The current GNOME 2.0 Platform Plan Proposal.

Technology adoption in GNOME 1.x

For the past year we have been working in producing a number of very interesting technologies for GNOME. These technologies have been developed around the GNOME 1.x development platform.

This approach has enabled us to deploy new technologies in GNOME without revamping the complete system, breaking binary compatibility or breaking source compatibility with previous major releases of GNOME.

The GNOME 1.2 release added to the development platform libglade (for simplifying GUI development) and gdk-pixbuf (a first step towards handling images correctly). GnomePrint and LibOle2 were Gnumeric-internal libraries and a few other applications use them.

The GNOME 1.4 release will expand the platform with a number of interesting technologies:

  • GNOME VFS: This library provides an asyncronous API integrated with Gtk that application developers can use to access files on remote servers, inside compressed files, trough webdav, ftp and more.

  • Bonobo/OAF: The component system that is being used by large applications like Evolution, Gnumeric and Nautilus. Various other components are being developed using Bonobo to provide a better development platform and a more reusable one: HTML rendering (gtkhtml, mozilla), HTML editing (gtkhtml), Web browsing (mozilla, e-browser), Plotting (guppi3), image rendering (eog), PDF viewing (xpdf), Vector rendering (sodipodi).

  • GConf: A configuration system that addresses a number of problems that we had identified in the past: a way of notifying applications that a setting has changed and a way of having multiple applications making changes to values in a reliable fashion.

  • Gnome Print: Various applications besides Gnumeric have started using Gnome Print for their printing needs.

Integration of the existing technologies

The way in which these new technologies have been deployed in GNOME has helped us keep the development going, and at the same time avoid major disruptions in the existing code base.

The only problem is that sometimes when we want to implement new features or do a better integration job, the the dependencies involved have stopped us from doing this, or have forced us into creating new modules which supercede the previous platform.

This is not ideal, and we of course want to fix this issue. But before we can fix this issue, we need to come up with a strategy that will allow us to have as little disruption as possible and allows us to move on to the new platform in a way that is not too painful.

The problems ahead

Given that Gtk 2.0 has broken both binary and source code compatibility, there is a large ammount of work that lies ahead just to port our applications to the new platform.

There is currently an attitude that since Gtk 2.0 is breaking both source and binary compatibility it is ok to make any kind of changes to the system. I would like to argue that this is not an ideal situation, and that we should aim for small, concrete tasks rather than complete overhauls of the development platform.

Currently there is no document that describes how applications, libraries and widgets need to be ported to the new platform. The lack of documentation in the past has been painful to everyone involved, and this shift to a new platform is likely going to hurt us if we lack such a document.

Planning for the future

We are faced with a challenge here: balancing cool features with a planned and organized schedule for rolling out the 2.0 platform.

As I mention in the Delays appendix the free software community has a tendency to include features because they are there or because we can do it, skipping over a plan and imposing delays that might be bad for the project.

(I am not claiming that I am safe of guilt, btw).

With the above considerations, I would like to introduce the "Goals" document that goes into more depth around how we should look at the goals we set for the GNOME 2.0 release.