The future of The GIMP
December 2000 by Sven Neumann & Michael Natterer
This document is meant to be a RFC (Request For Comments). Nothing described
in here is a fixed decision, everything can and should be discussed. The
reason for writing this document now is that the final release of gimp-1.2
is very close and we need a roadmap for the time thereafter. We will propose
our ideas for the future of The GIMP here. A lot of these ideas are based
upon the discussions we had at the 1st GIMP Developers Conference which was
held in Berlin earlier this year (see http://www.gimp.org/gimpcon/).
Our core proposal is to have three branches after the 1.2 release. We'll
tell you later why we think this is a good idea. First let's have a look at
the branches and see what they provide:
The 1.2.x "Maintainance" branch
-------------------------------
This is the usual maintainance branch. Only bug-fixes go in here and
only if serious bugs are found and fixed, there will be a gimp-1.2.x
release. We will also consider putting upcoming stable releases of
important plug-ins (like Gimp-Print) into the stable branch. Hopefully not
too many releases will be necessary. Probably someone will port GIMP-1.2
to GTK+-2.0 once this becomes available and an 1.2.x release will be made
supporting GTK+-2.0. This would be similar to what happended with gimp-1.0.3.
Actually we think that it makes more sense to do the port to GTK+-2.0
entirely in the 1.3.x branch as described below.
The 1.3.x "Cleanup for 2.0" branch
----------------------------------
This is a development branch, which means that new features go in here.
As the name suggests, we would like not to include too many new features
here but to focus on other goals:
o Port gimp to gtk+-2.0
As soon as the GTK+-1.3 branch stabilizes and the API has settled (which
seems to happen right now), the gimp-1.3 branch will start to require this
development version of GTK+.
o Cleanup some internal structures
As explained in more detail below, the gimp-1.2 codebase is full of crap.
The main goal of the 1.3 branch should therefore be to cleanup the
internal structures without changing the external functionality and look
and feel of the application. All data objects have to be converted to
real GTK+ objects and all dialogs that provide a view on these data
structures (think of brushes, layers, ...) should make use of a clean
model-view concept. A proper controller interface needs to be provided
to enable changes to the underlying data structures via a clean interface,
no matter if the request comes from the main application's dialog or
from some plug-in.
o Implement a few, well defined, new features
A lot of nice ideas have come up in the meantime (have a look at the
wishlist on our bug database for some examples) and some of them should
be comparibly easy to implement. We will need to make a well-defined
list of features and accept new features only after thoughtful discussion
on the mailing-list. Only if we limit ourselves to a short list here,
we will be able to have an 1.4 release within the next year.
o Think about a new way to handle plug-in distribution
As more and more plug-ins go into the main gimp distribution (and a lot
of plug-ins are wating to be included), it becomes difficult to maintain
them all. Core developers are busy enough with the core application and
shouldn't have to fiddle with all those plug-ins. If we can think of a
better model for plug-in maintainance and distribution, we should try to
implement it in this branch.
Once this work is done there will be an 1.4 release. This release will
work with GTK+-2.0 and will provide a backwards-compatible plug-in API.
Probably we can not achieve this goal due to unavoidable changes to the
plug-ins' Gtk+-code but it shouldn't be hard to port plug-ins to gimp-1.4.
The 1.9.x "Building GIMP 2.0" branch
------------------------------------
This branch will start in a clean gimp-2.0 module on CVS. After setting up
a directory structure (which should be much finer grained than what we work
with now), work will begin to implement the design as discussed at the
GIMP developers conference. Fortunately some work has already been done:
o GEGL -- Gimp 'E' Graphical Library
GEGL is an image processing library based on GtkObjects written mainly
by Caroline Dahllof and Calvin Williamson. This library will provide the
core gfx engine for gimp-2.0. It is available with lots of documentation
in the gegl module on gnomecvs.
o GCim -- The convergence integrated media object and utility library.
We can't tell you too much about this yet, since this library has not
yet been released to the public. This is something we (Mitch and Sven)
and others have worked on during the last months at our employer, the
convergence integrated media GmbH. We will release this as open source
very soon. Basically it's an XML enhancement library for GTK+. It will
allow us to write serializable and deserializable GObjects with little
effort and it provides a mechanism to transparently send GTK+ signals
to other applications via XML-RPC. Expect more info to be available soon.
Since we haven't yet managed to write down all our ideas developed at the
conference this June, I can only point you to the gimpcon website located
at http://www.gimp.org/gimpcon/ which has a review that explains some of
our ideas. We will certainly have to outline the new design in more
details before we can actually start to implement it.
Our reasons
-----------
It's now time to explain why we think that having three branches is a good
idea and why we think development should continue as outlined above:
We believe that the gimp-1.2 codebase is very hard to understand and to work
with. A lot of the internal structures date back to a time when the GTK+
object system was not available. During the last years some code has been
migrated to make use of the GTK+ object system and at some place you can
even notice some design principles like model-view (only if you look very
close). Most of the code however is still pretty crappy and full of
side-effects. This has led to a lot of problems and unexpected bugs during
the last development cycle. We have learned that adding new features to this
codebase most likely breaks code at places you didn't (and probably couldn't)
think of. This is the main reason why we propose to develop gimp-2.0 from a
clean tree. On the other hand, starting from scratch will mean that for some
time there will be no real application to test changes in. That's why we
believe it makes sense to perform a lot of the code cleanup in the old tree.
By limiting ourselves to a small set of new features we could manage to bring
out gimp-1.4 not too long after GTK+-2.0 was released.
Links
-----
http://www.gimp.org/ GIMP homepage
http://www.gimp.org/gimpcon/ GIMP Developers Conference
http://www.gegl.org/ GIMP 'E' Graphical Library
http://www.convergence.de/ convergence integrated media GmbH
Feel free to send updates/comments/fixes/flames/whatever. We will keep this
document up-to-date and post new versions when neccessary.
Sven & Mitch
