Basic Principles

Avoiding Hubris (GIMP 2.8)

image link-topic-sf0.jpg

1. The Problem

Time for a surreal nightmare. You take a book off of your bookshelf and open it. When you're done reading, you try to put it back on your bookshelf, but to your surprise it comes to life and refuses to go back. It thinks that it's become a Kindle, and refuses to be placed on a shelf alongside mere books. In order to put your recalcitrant book back on the shelf, you have to hook a printer up to it, print out its contents, and put that printout on the shelf. You then have to throw away your original book (which now thinks its a Kindle) as you have no use for it and can't save it anywhere.

This is a nightmare, certainly. It would be an amusing nightmare if done by Warner Brothers or Disney. It would be an alarming nightmare if done by Kafka.

It is also the GIMP 2.8.

Starting with release 2.8, The GIMP deliberately - as a matter of considered policy - changed the way that opening and saving image files worked. If, in GIMP 2.8 or later, you open a JPEG image it forbids you from saving that image. You can't do it; it isn't allowed. If you do want to save this JPEG image, you must instead "export" it to JPEG format and save that exported version. You must then deliberately discard the opened version of your image.

2. The Official Rationale

The way in which the GIMP's developers rationalize this nightmare is this: internally, the GIMP operates using its own representation of the image. This format is very capable - it has to be, because it must be able to handle all of the features of all of the kinds of image formats that the GIMP can handle. The GIMP can also save files in this native format, which preserves it so that you can continue to take advantage of these comprehensive features. This can, of course, be handy if you have decided to commit your development process to The GIMP's own format.

In previous versions, the GIMP would open an image (say, a JPEG) and convert it silently to its internal format for use. (This is excellent, expected, behavior.) You could then edit it using the full capabilities of the GIMP rather than some subset limited to the image format you loaded. Then on saving, it would remind you in a popup window that it couldn't necessarily save all of the features you'd worked with and allow you either to save the image in its original format (possibly losing some of these) or in the GIMP's own format (rendering it incompatible with the rest of the world). This was all perfectly rational.

But this extra popup annoyed GIMP developers, who naturally were partisans of the GIMP's own format. So with 2.8 they changed the behavior. The GIMP still silently converts images to its own format on opening (good), but now will not, ever, let you save to any format other than the GIMP's own format. To actually save an image back to its own format, you must instead "export" it. You must then discard-without-saving your opened image.

This was a deliberate, considered design change, and the GIMP's developers seem sincerely to believe that it is the One True Way and that anyone who thinks otherwise is wrong. Regrettably, it is they who are very deeply wrong. Not only is this design change annoying in regular operation, and not only does it violate basic principles of user interface design, more imporantly it violates the spirit of Linux, the open-source movement, and the making/hacking community.

3. Operational Issues

At first glance, it would seem that this change might be only a minor annoyance: just invert the meanings of "export" and "save" to compensate for it. But this is not so.

The GIMP, sensibly, keeps track of whether a file was changed. If you try to close a file without saving, the GIMP will ask you if you're sure - do you want to discard the work you've done? Any major application (LibreOffice, etc.) works the same way.

But if you export a file, the GIMP has no concept that you have in fact saved your work. To the GIMP, you haven't. So unless you actively remember, yourself, that you have saved-by-exporting you have no way of knowing on closing an image if you've really saved it or not. Worse, since the only way to actually, properly, save a file in the GIMP is to export it, the GIMP will always warn you that you haven't saved your work even when you have.

Now, I expect my computers simply to run indefinitely. I come from a mainframe background, where minutes of downtime could in fact cost millions of dollars. I simply do not accept as valid the need to reboot Windows and Macintosh machines on a daily basis. The underlying Linux system is in fact as reliable as mainframe operating systems, although Gnome and company are trying to bring its MTBF down to the Windows/Macintosh level. In consequence, I run individual projects (such as editing a portion of my website) for months at a time. I'll leave GIMP sessions open for this long, sometimes.

With GIMP 2.6 and earlier, I could rely upon the GIMP to warn of lost work over this indefinite timespan. Now I either have to limit my GIMP sessions to immediate needs or write little notes to myself to remind me that I have, or have not, saved work in an image that I might last have worked on months ago.

This behavior is simply unacceptable for any application intended for serious work. It turns the GIMP, once a capable system, into a toy.

4. Hubris vs. Humility

But there is a deeper issue here which is troubling (rather than simply irritating). The underlying reason for this change was not valid logic (the logic isn't valid), but hubris. It came from an overwhelming arrogance - a feeling that one is like unto the gods.

If the problem was simply logic, then it would be simple to point out to the GIMP developers (as has been done, repeatedly) that this change defies all logic and every principle of good user interface design: Open X, Save X fails. You can't get worse than that. But the GIMP's developers have demonstrated (repeatedly) that they simply cannot comprehend this. The problem isn't logic, it's hubris.

The particular god in this case is Adobe. The GIMP is suffering from severe Photoshop envy. If you are Adobe and dominate the commercial market, yes, you can afford play god and set the standard. You can save by default to .PSD and assume that everyone must follow you.

But the GIMP is not Photoshop. XCF isn't PSD. It's a minor format with little support outside of the GIMP itself. Changing the GIMP to pretend that it's as important as Photoshop is vanity.

The essence of the maker's way is one of humility. Whether it be in Linux, or software hacking, or hardware hacking, or any project which involves open source and an open mind, the most basic principle is humility. You're working with things outside yourself, with things bigger than yourself - and trying to make new things to fit gracefully into the world. Linux, like water, is the universal solvent.

By way of contrast, the whole point of the world of proprietary software that we're trying to get away from is hubris. Commercial software must at every instance pretend that it is god-like in the hope that it will triumph over its competition and become the god-application of the day.

To the extent that any open source / makers' project attempts this kind of hubris, it attacks us all.

5. The Solution

There isn't any. The situation is well and truly fubared.

There was a patch to the GIMP a couple of years ago ("GIMP classic") to restore GIMP 2.4 behavior before even the user interface problems of GIMP 2.6 (which didn't yet include this GIMP 2.8 save/export bug). But it isn't clear that it will work with current versions of the GIMP [TO DO: check]

Other than that, the only solution is to go into the GIMP's code and fix the problem - and do it again and again for every new release.


Select Resolution: 0 [other resolutions temporarily disabled due to lack of disk space]