Welcome to my new site; both the new domain name setofskills.com and the new layout. So why change domain? Partly for a fresh start. This is now a general programmer's blog that will try to include some interaction design perspectives, not a GIMP developer blog. Partly to remove the accidental Google Chrome association chromecode.com got (which I registered 5 years before Google Chrome was released by the way). Since my old site probably is perceived as a bit dead since the last blog post was more than 4 years ago, I thought now would be a good time to change domain. All old blog posts have been ported to the new site though.

So why change layout? Partly to freshen it up, partly to learn new things. You see, my old site had the blog hosted by Blogger, and the rest on a cheap Danish web host. The new site is hosted in the Amazon cloud and is built on fresh(er) front-end technology such as SCSS, CSS3 animations, screen size responsiveness, Bootstrap, Jekyll and RequireJS. There's also HTTPS for good measure. The color scheme is inspired by my new main editor Sublime Text. So long Emacs, and thanks (not) for all the fish Lisp.

You might also have noted that tasktaste.com has been taken offline (and taken over by some SEO company). Its usage was pretty low, and keeping it alive was not worth it. I might resurrect it someday, but then it will be hosted on this domain rather than having a domain on its own.

As for time over for coding, it is still low. I now have two kids to raise. Occasionally I get some code written though, so keep your eyes open for announcements in 1-10 years.

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.

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.

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 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)

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.

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.

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 ;)

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.

The more people that use the latest GIMP code from git the better. It keeps the required effort to contribute code upstreams small, which in turn increases the likelihood of upstream contributions, and it makes bugs more vulnerable to early discovery which minimizes their impact.

However, keeping up with GIMP from git means extra work compared to using prebuilt packages. Unless you know of an easy way you might not withstand it. What follows is a description of how I do it, which is almost effortless once setup. I assume you know how to install necessary dependencies (note you can use the method I describe for the key dependencies, including babl, GLib, GEGL and GTK+), what "the install prefix" means, and that you run Linux. The approach I use differs in two principal way compared to the many guides found on the net:

1. I use autoconf's config.site feature instead of setting up environment variables manually
2. I install in my home directory

export PATH="$PREFIX/bin:$PATH"
export PKG_CONFIG_PATH="$PREFIX/lib/pkgconfig:$PKG_CONFIG_PATH"
export LD_LIBRARY_PATH="$PREFIX/lib:$LD_LIBRARY_PATH"
export ACLOCAL_FLAGS="-I $PREFIX/share/aclocal $ACLOCAL_FLAGS"
export XDG_DATA_DIRS="$PREFIX/share:$XDG_DATA_DIRS"

git clone git://git.gnome.org/gimp
cd gimp
source $PREFIX/share/config.site
./autogen.sh --prefix=$PREFIX
make
make install

git pull --rebase
source $PREFIX/share/config.site
make
make install

The above approach works for as good as all GNOME projects, including GLib, babl, GEGL and GTK+. This makes it easy to adapt to GIMP's build requirements of these and other libraries even if your distro doesn't meet them. Let me know if you have problems!

GIMP has a UI that feels rather cluttered. Not only because of the many windows, but also because of the contents of each window. It is not hard to point out areas for improvement. The last few weeks I have worked on getting rid of one thing that contributes a lot to the clutter in docks: the docking bars.

The docking bars were used as drop targets when moving around dockable dialogs with drag-and-drop. They had many problems:

1. They took up space, even when no drag-and-drop was going on
2. They were not pretty
   
3. They were only at the top and bottom of a dock, preventing dockable dialogs from being dropped in the middle of docks

When the news of the introduction of a single-window mode in GIMP 2.8 hit the net it became clear what an incredible desire for something like this there was. The reactions have been overwhelmingly positive, and this really helps to motivate you to hack on it. The news also revealed an interesting but previously rather anonymous group of people: multi-window zealots despising the idea of a single-window mode in their beloved multi-window application. I suspect they don't realize that single-window mode is going to be optional...

I am happy to tell that the implementation of the single-window mode is progressing well. I have refactored the code to allow docks to be put inside an image window and Michael Natterer have refactored the code to allow many images to be shown in a single image window. The code is already combined and pushed to git master and you can get a very good feeling for how awesome the single-window mode is going to be by trying out the current code. Above is a screenshot of a live GIMP built from git master with 'Windows→Single-window mode' enabled. You can see the toolbox and dockable dialogs docked to the image window and the tabs for images in the image window at the top. Still a lot of things left to do though.

A couple of weeks back we took one important step closer to a GIMP 2.8 release by releasing GIMP 2.7.0. One of the enjoyments of contributing to a project like GIMP is that a lot of people is affected by your work and you get immediate feedback on what you do.

GIMP 2.7.0 was mildly received, which is understandable since none of they highly requested features were implemented. A lot of people over at Digg are disappointed about us not doing a single-window mode for 2.8. But again, that will come in 2.10. Then there's the usual stuff about requests for non-destructiveness and higher bit depths, which is also scheduled for 2.10. And as usual, most people are pretty clueless. I was happy to found one guy that knew what he was talking about, drag.
Update: Just to avoid confusion: after this post was made there was a change in plans and the addition of a single-window mode is now planned and in progress for 2.8.

A lot of people over at GIMPUSERS.com want the old save and "export" mechanism back. The conclusion to draw from that is that they are not part of the user group we are targeting. We are not trying to make GIMP into an excellent JPEG touchup application, we are making GIMP into a high-end photo manipulation application where most of the work is done in XCF.
Update: Based on this poll it seems this was just a matter of a vocal minority. I would also like to clarify that "they" were referring to this vocal minority, not GIMPUSERS.com as a site which I really like.

The reactions over at GimpTalk are much nicer. Not any complaints, just comments on the release. GimpTalk just became my favourite GIMP community!

I have promised myself to write at least one post per month in this blog. In this post, I will give a general update. In essence, we are simply working our way through the important items on the 2.8 milestone list. Once those are taken care of, and once the successful GSoC 2009 projects have been merged, GIMP 2.8 will be released.

With the release of GIMP 2.8 we have some really interesting times ahead because it has been agreed that the version after that will not be released until we have completely ported GIMP to GEGL and introduced long sought for features such as a single-window mode (which I will personally ensure happens), layer groups (currently hacked on by mitch), and constructs similar to adjustment layers found in PS.

Hopefully, we will also manage to release the first development version of GIMP 2.8 as soon as possible, GIMP 2.7.0. We're just waiting for a GIMP 2.6.7 release first that the currently very busy Sven is trying to get out.

A lot of things has happened since my first patch for GIMP was commited almost three years ago. GIMP has undergone two stable releases, used three version control systems, improved a whole lot, and my involvement in the project has increased significantly. There is however a lot of work that still needs to be done, the two most important being improving the user interface and finish the integration of GEGL.

In this blog I intend to describe my continued involvement in creating the best free, open source image editor in existence together with people like Sven Neumann, Michael Natterer, Øyvind Kolås and Peter Sikking.