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
