Single-window mode feature complete

Since some days ago, single-window mode for GIMP 2.8 is feature complete. That means that I'm not planning to add more single-window mode related features into GIMP 2.8 such as those Peter Sikking originally envisioned that I haven't implemented yet. This is how feature development should be done anyway: incremental and continuous improvements. If you go for the whole thing at once, it will take forever to finish what you started. To my knowledge, there are only a few annoying but harmless bugs left to fix before single-window mode is ready to be included in a stable release.

As for GIMP 2.8 development as a whole, we're still on track for a late 2011 or early 2012 release of GIMP 2.8. There are still some things we really need to fix before we can make a release without embarrassing ourselves, like supporting layer masks on layer groups and making it possible to easily move individual layers in a layer group with the move tool.

If you're curious about what single-window mode will be like in GIMP 2.8, I suggest you keep your eyes on gimp.org and look for the GIMP 2.7.3 release which should happen any day now. I also encourage you to file good bug reports if you find any bugs.

GIMP 2.8 schedule on tasktaste.com

A GIMP 2.8 release date matters a great deal to a lot of people. It matters to users because it will bring some long awaited features to them. It matters to book publishers because they would like to have books ready. It matters to translators because they want translations to be done. It matters to GIMP developers because it is an important milestone in the history of GIMP development.

Estimating completion of software projects is tricky however, especially for projects driven on a volunteer and spare-time basis like GIMP. An estimate of a GIMP 2.8 release date will by nature be volatile and keep changing to the day GIMP 2.8 is finally released. There needs to be an easy way for people to keep themselves updated with the GIMP 2.8 development progress and release date estimate.

After realizing this I started to look for a tool that could help. I knew I wanted a schedule to be a public web page with no login required. I wanted this web page to be graphic, visualizing progress. I also wanted it to be easy to keep up to date, and I wanted it to be free and open source. I did not find a tool like this, so I decided to write my own. The result is tasktaste.com. Go ahead and create a project schedule yourself!

The GIMP 2.8 schedule is found here. Whenever you want to update yourself with GIMP 2.8 development progress and get an automatically calculated release date estimate, simply revisit that page.

Why GIMP 2.8 is not released yet

Back in January 2010 I estimated the release date of GIMP 2.8 to December 2010. It is now February 2011 and there is still a lot of things left to do. In this post I will give my view of why this is.

The way I see it, there are three main reasons we have not been able to release GIMP 2.8 yet. I want to stress that I don't mean to put blame on anyone, I am just making observations. The reasons are:

1. Less time for GIMP development for key resources
2. Features are being developed on the main branch
3. A tendency among developers to repeatedly start working on new things

The first reason is not something you can do anything about in a project developed entirely on a volunteer basis. The work and family situation for people changes all the time. Sometimes there is time over for GIMP development, sometimes there isn't. This is not a problem per se, but it becomes a problem if a developer that gets less time for GIMP development has an incomplete feature on the main branch. It blocks releases and in the worst case it also blocks development of other features.

The second reason is that we develop features directly on the main branch. That this is a problem is highly related to that developers come and go. In fact, it is the reason we have long development cycles overall. There is almost always a feature on the main branch that is incomplete. This has the sad side effect that if someone contributes a complete feature in the beginning of a development cycle, it will literally take years before that features reaches a wide audience. An important factor in making it fun for people to contribute to GIMP is thus lost: quickly getting feedback and hopefully praises from our large user base. I believe this is one of the reasons GIMP has so few contributors.

The third reason is also not something you can do anything about in a project by volunteers. People will work on what they find fun and rewarding, and sometimes you get bored working on old things, especially if you bump into problems. This is again only a problem if the work is big and happens directly on the main branch. We end up with a lot of started but not finished work.

The solution to all our problems is the same. We need to begin developing big features on feature branches and merge them to the main branch when they are ready. Changing our way of working is not going to be easy, because it requires a different mindset for everyone involved. But if we don't do it, our long development cycles will make GIMP remain unattractive for new contributors and even ourselves.

Just like in January 2010, the plan now is to get GIMP 2.8 development under control again with a schedule. This time however, it will not be through a spreadsheet version controlled along with the GIMP source code, but through a web based tool I have been working on for the last few months. That is a topic for another blog post though...

Finally a small notice; I have replaced BuildBot with Jenkins for our nightly tarball builds. The new URLs are:
babl-git-master.tar.bz2 (HTTP) (FTP)
gegl-git-master.tar.bz2 (HTTP) (FTP)
gimp-git-master.tar.bz2 (HTTP) (FTP)

Nightly GIMP, GEGL, babl tarball builds

I have spent the last few weeks working on setting up nightly tarball builds of GIMP, GEGL and babl. Today I am glad to announce that this is up and running.

This means that from now on you don't have to wait for development snapshots or build from git in order to test the bleeding edge GIMP code. Nightly tarballs can be found at:
ftp://gimptest.flamingtext.com/pub/nightly-tarballs/

It also means that the work I have put on infrastructure and authoring of test cases is more valuable now that the tests are continously run, and that we have a better GIMP development setting where regressions can be discovered as early as possible and thus also more easily fixed.

A natural extension to this is to also do nightly builds of binaries, in particular for Windows for which it is quite inconvenient to build from source. But that will be a later project...

A big thanks to Cameron Gregory at FlamingText.com who donated the server for the nightly builds.

Automatic tab style and removed tab title bar

I currently have less time over for GIMP development than I used to have. Puss på dig Emma! ♡ :) Nevertheless, I've just landed two changes to the UI. The first one adds a new tab style to docks, the second one removes the rather space inefficient tab title bar.

The new tab style is called 'Automatic' and makes the tabs in docks as big as possible given the available space. If you have one dockable dialog in a wide dock, the tab will be an icon and a title. If you have many dockables in a narrow dock, the tabs will be just icons. The Automatic tab mode is dynamic, resizing a dock will update the tabs in a dock live. This tab style is also the new default tab style.

Following the Automatic tab style I could remove the tab title bars. The removed tab title bar had two purposes. Hosting the tab menu button and acting as a drag-and-drop handle when no tabs were present. The first has been addressed by moving the tab menu button up to the tabs and the second has been addressed by always showing tabs.

Along with the removal of the docking bars a while back, the result is that GIMP has gotten a cleaner and more space efficient UI. There's a lot of things that could be further improved of course, but this is what I wanted to do for 2.8. And the single-window mode. Speaking of, I haven't had much time for that lately either, but I'm sure it'll all be fine eventually.

GIMP 2.8 development still under control

A while back I announced the creation of a schedule for GIMP 2.8 development. I've made sure to keep this schedule up to date, and after a bunch of initial adjustments such as postponing some feature and adding others, the schedule has now stabilized a bit. The estimated date for a release candidate is still in December 2010. Tracking progress with a schedule really helps you to feel in control of development. The 2.4 development cycle which I were around in the end of, and the 2.6 development cycle which I were fully part of, were more chaotic with no commitment to a delivery date. This is perfectly fine for many, but I prefer structured development.

As far as development goes I have continued working on the UI in general and single-window mode in particular. There is now only one major thing missing before single-window mode is ready for some real usage, which is proper session management of the single-window mode. That is, it of course needs to be made possible to start up in single-window mode and the UI layout in single-window mode needs to be preserved. There are some quite big details to sort out here, so I'm basically waiting for Peter Sikking to find time to write a UI specification on how it should work.

In terms of more concrete changes I have for example added a new menu item under the Windows menu labelled Hide docks. This makes the crucial feature to hide dock windows and docks with Tab discoverable, a feature most people don't know about but wish they knew sooner when you tell them about it. I've also made the setting preserved across GIMP sessions, so if you close GIMP with the docks hidden, they will remain hidden when you start GIMP the next time. Another change is that dock windows now only have the active dockables in the title, instead of all tabs, to avoid hugely long window titles. I would also like to take the opportunity to point out that there is a Recently Closed Docks sub menu under the Windows menu, even in 2.6, which contains dock windows you have closed, something many people don't seem to be aware of.

I'll let that be the end of this general update. And sorry Fredrik for not making a post in February ;)

Multi-column dock windows and 2.8 schedule

The code refactorings and clean ups that have been made to enable single-window mode to be implemented has also resulted in improvements to multi-window mode. The most significant is the support for multi-column dock windows, as you can see used in the screenshot above. People having dockables on one screen and an image in full screen on another will probably find this useful, for example. Before this, you could only have one column of dockables inside a dock window.

I also have a fundamentally different but arguably a more important announcement. There now is a schedule for GIMP 2.8 development and thus also an estimated release date, which right now is 2010-12-27. Creating a schedule was not completely uncontroversial. People pointed out that if we have an estimated release date it will surely be misinterpreted as a definite release date, and if we don't meet it, people will be annoyed. People will probably misinterpret, but that is less worse than the current situation where people speculate about dates that are way too optimistic, giving the impression that we are constantly delayed. Besides, without a schedule it is very hard for us to take decisions on what features to include and what features to not include in each release. I think that in the end having a schedule will only have a positive impact on development.

And finally, thanks to Alexia Death for letting me use her graphic in the screenshot above.