« GIMP 2.8 versus FontForge | Home | On pronouns and UIs »

NoXCF-GIMP: an image editor, not an XCF editor

Sat 19 May 2012 by mskala Tags used:

I have forked the GNU Image Manipulation Program, and you can download my version from this GitHub project. See my earlier posting for discussion of why. In few words: mainline GIMP is an XCF editor, not an image editor. My version is an image editor.

Although I disagree in the strongest possible terms with the GIMP team's vision of which users are important to support and which users should be told to fuck off, I have to say they did a good job of structuring their code base. Once I finished cloning the appropriate repositories it only took me a few minutes to find the things that needed to be changed to restore some semblance of normalcy to the interface. What's posted on Github now is very quick and dirty, but it already basically works.

I have changed only the "master" revision in the linked repository. If you want to try it, you'll have to download the source and compile it yourself. If there's demand I can probably put together at least an Arch Linux x64 binary package, but binaries for other operating systems or architectures aren't going to be easy. I could probably backport my changes to 2.8 if that's useful to anybody.

What I've done so far is to make the former "Export" command into a "Save" command. The former "Save" command is now a "Write XCF" command. The keyboard shortcuts have been changed accordingly. The "you should use some other command instead of the one you entered!" dialog boxes have been deleted with extreme prejudice. Saving in any format will now set the "file has been saved" flag, so you'll receive a warning about unsaved changes on exit if and only if there actually are unsaved changes. And that's about it.

It would be nice if XCF and all other formats could be saved with the same command instead of the current separation; but that will require a lot more work than just changing the menu items around. It's probably not completely prohibitive, though - much of the code is already shared between the two, with just some if statements in the middle of the "save" command to prevent it from being able to save XCF if it was invoked as "export" or prevent it from being able to save anything else if it was invoked as "save." Seeing that doesn't decrease my anger at the GIMP developers, because it's clear there is absolutely no technical reason the formats really need to be separated - they are separated in order to deliberately create an inconvenience for users, because that is what the high-priced usability talent thinks is needed in order to be taken seriously by the cool kids.

Other things that could be changed and haven't been yet: lots of online documentation, help files, translations, etc., still refers to the "Export" paradigm and should really be changed to reflect what the code now does. This was intended by the mainline developers to be a fundamental change in the nature of GIMP; it may be naive to think we can undo it just by swapping around a few menu item names and setting a flag in the unsaved-changes logic. The name of the entire package should really be changed; "gimp" is a taboo word in some communities and really not suitable for the name of a software package that wants to be taken seriously and compete with commercial products, and both I and the mainline developers would probably prefer that it be as difficult as possible to confuse the fork with the mainline version. And this might also be a good opportunity to change some other small things that annoy me about mainline GIMP, such as the default (fortunately configurable, but it should not be default) of making the toolbox a "special" window that screws up the window manager.

How much enthusiasm I will have for the ambitious project of making it all really right and continuing to track mainline development into the indefinite future will depend on whether anyone other than me uses this one. I don't really want to be in the business of image editor development; I have plenty of other projects and just want to have an image editor I can use myself without finding myself contemplating a tri-province killing spree every time I try to exit after saving my changes.

So, if you like this: ideally, you'd take over its development yourself! Failing that, you could link to it or tweet it or whatever, because that's what will encourage me to continue improving it.

10 comments

p3r
I am also not a fan of the direction of GIMP and have been creating patches against the official source the restore the multi user UI that was dropped in 2.6. I haven't yet done a patch against 2.8 (2.7.4 was the latest I had done) but I might patch against your code.
p3r - 2012-05-20 16:46
Matt
Good to hear from you. Looking at the three points listed on your page, I think the "remove empty window" one is very similar to the "single window" change the mainline implemented in 2.8, so that patch may no longer be needed. I think your "All toolbox windows top level so they can be controlled by system panel" is the same issue I mentioned about the Toolbox screwing up the window manager, so if you have a patch for that, I'd like to have it. As of 2.6 it was a configurable option in mainline GIMP, and I'd been getting acceptable results by just turning that option off; I'd probably be happy with simply making the default for it be "off" (all windows treated as ordinary windows) but if you've spent time looking at the issue in detail, maybe you'd know better than I whether other changes beyond that are needed or useful. I don't have any strong feelings about restoring the "Toolbox menu"; there is a "Tools" menu in the current version with entries for the same tools that are in the Toolbox, but I don't know if it was removed and added back, or if what you want to restore is more than that.
Matt - 2012-05-20 17:57
Richard Barrell
I am strongly curious as to what your opinion of CinePaint might be. It is an image editor that was forked from GIMP a while back with the goal of supporting colour depths that GIMP doesn't support, such RGBA with 32-bit floats in all four channels. I don't know if GIMP has since added support for such things as I haven't used an up-to-date version in a while now. CinePaint also solves the GIMP-is-a-horrible-name problem quite neatly.
Richard Barrell - 2012-05-29 15:21
Matt
I've heard of CinePaint, but have never tried it. Now might be a good time to do so. A wider variety of colour depths isn't all that relevant to me (mostly, I just want to edit JPEG and PNG images for Web display, where 24 bits is all we can expect), but especially if CinePaint is stable, that would be really nice. On my forked GIMP version I've been having a lot of trouble, which I'm sure isn't associated with any changes I made, with basic stability of the GEGL library on which GIMP depends.
Matt - 2012-05-29 16:18
Richard Barrell
That seems unsurprising. I can't attest to it from my own experience, but a friend of mine once wrote an image editor with a really unusual UI, and based it on GEGL. He seemed to be running into no end of GEGL bugs.
Richard Barrell - 2012-06-23 18:56
Åsmund Ervik
Thank you so much. I was thinking I'd fork the code and to this myself, but decided to have a quick look in the AUR just in case someone else had. To wit; there was your package. Thank you again, and I agree strongly with you that the GIMP developers are being stupid idiots and expecting every user to be a professional graphic designer.
Åsmund Ervik - 2012-06-27 05:50
Matt
Oh, cool! I didn't even know it had made it into the AUR.
Matt - 2012-06-27 07:19
Timo
I have to say: Thank you very much! I would like this in the Debian, too...
Timo - 2012-07-14 21:00
idiot
Thanks for doing this, now there is both Akkana Peck's plugin and your fork to point people at when they start rambling about how they hate GIMP 2.8 and want their money back :-)
idiot - 2012-09-13 04:06
Visti Andresen
You are probably my hero!

While I haven't tried to compile your code yet it sure sounds promising.
The fact that I would have to export to XCF, which is a sort of "proprietary" format anyway doesn't bother me, not if ctrl+s saves it to XCF after the export.

Mainline GIMP should actually display a warning "You haven't exported your work in a format that can be read by others, your work will be lost if the software dies off due to UI changes"
(I actually like XCF for certain tasks, but I do believe I make better format choices than a computer with a fixed answer)

Fun fact:
You fork should be called GIMP, mainline should be called GXCFMP.
(If they like convoluted work flows that much perhaps they also like convoluted names?)
Visti Andresen - 2013-03-31 15:28


(optional field)
(optional field)
Answer "bonobo" here to fight spam. ここに「bonobo」を答えてください。SPAMを退治しましょう!
I reserve the right to delete or edit comments in any way and for any reason.