GIMP Development Update
gimp.org
gimp.org
People might say, "You can just join the project and fix it yourself." But the team and community actively resist change and sabotage efforts to make GIMP more mainstream.
It was like using a computer program in your dreams where things don't really have to make sense.
My theory is this is a classic OSS problem where everyone wants to contribute their pet feature but the project lacks discipline and nobody wants to remove, organise, and improve (especially where the latter can be 10x harder and more tedious then the former). This could be an argument for opinionated leaders in OSS projects, because at least they'll say 'no' and do things 'their' way a lot of the time, which is often better than the 'anything goes' philosophy.
I only need to do somewhat basic stuff these days, so photopea.com is more than enough for me. However, now that I look it has tons of new features. Nothing to install, is ad-sponsored by default, and runs entirely client-side.
IIRC, this is a lone developer, who has previously refused what seemed like lucrative catch & kill acquisition offers.
Here is a post with lots of info:
You would have been just as lost, if not more, in Photoshop (if you had never used it before.) You were doing a simple job that should have been done in a simple program.
Those who disagree are welcome to fork- and maintain it, if the users see value in it, they'll switch.
I think it's a lesson in how not to run an open-source project. I put it in the same category as Darktable, which gives off that exact same bad first impression.
If you just tried Photoshop 2 or 3 times, you'd fail to get anything accomplished either. GIMP is a Photoshop replacement, not an MS Paint replacement.
Maybe the problem is that not everyone needs Photoshop, or to learn a tool at all, and GIMP comes as standard on every Linux install. Most people never have a need for it. They only need MS Paint (or rather Paint.NET or Krita.)
Thinking that you should be able to just roll in and immediately get stuff accomplished on Photoshop or GIMP is a misjudgment of the skill it takes to use professional tools.
GIMP's UI is fantastic, and its capabilities are incredible.
edit: another problem is that people make a living from using Photoshop because it's an industry standard, so they're motivated to learn it. For GIMP you had to take the same effort to learn something that you couldn't use professionally. Hopefully the improvements on color and non-destructive editing will improve the situation on that front. It's becoming something that, if I have the latitude, I can use on the job at a print shop.
This is is simply not true. Photoshop is popular even with non-tech users because it is possible to do things in Photoshop without having to figure out an illogical UI.
We're talking about 2026. GIMP had an excuse for its UI back in 1999. It doesn't anymore.
PS isn't that much simpler or more intuitive now than back then. It's an inherently more complicated tool.
The suggestion to fork it is in bad faith. A fork goes nowhere unless a critical mass of the development community goes with it, and if you've already driven away the critical mass that could sustain a fork, that can never happen. Don't worry, Gimp is safe, I don't think anyone organized enough to fix its problems thinks it's worth the effort anymore, they're all working on other things instead.
> A lot of new and existing contributors have submitted improvements to GIMP’s user interface and its user experience. We wanted to highlight their efforts, and encourage you all to continue sharing your feedback on our design issue tracker.
I see no active resistance. If you have feedback, maybe share it with them?
At this point it’s probably easier to accept that the GIMP UI is simply what GIMP developers want it to be.
True, it doesn’t make a lick of sense, but the same could be said about Turbotax, Jira, SAP… or God may have mercy on your soul, Avid Pro Tools.
It is what it is. It’s not like there are no alternatives anymore.
I share this link a lot in the hopes that more people take us up on it, and provide specifics on where problem areas are for their workflow. So many people use GIMP in so many different ways, even something that seems "obviously bad" to one group might not be encountered by others.
Then people can easily download and install it directly in GIMP, hopefully making everyone happy.
However, if you see an older issue that could use some UX design discussion, feel free to suggest it be moved.
In particular, it’s a photo editor at core. You can use it for postprocessing of other image types if you want, or for pasting together memes or whatever. But it’s not designed for e.g. doing illustrations or digital painting or sketches
This isn’t even unique to GIMP in that way. Photoshop is also a sub par art program (though admittedly they’re a little more flexible than GIMP). But if you wanted something better for than Photoshop and were ok with proprietary windows/mac software there’s clip studio paint and before that there was paint tool sai etc.
While until the rise of Krita being actually good (having tried it many times over the years prior, that’s some time around 2018) if you wanted Linux or just wanted FOSS, you had to use Gimp and that breed resentment at it being the wrong tool
The panels concept might be the most intuitive part of it, but Blender also has different panels and modes. And the tools being combined into few buttons is similar to CAD programs I've used.
Anyone enlighten me on actual usability problems (and not pedantry like "the spacing of these buttons is uneven"?) Perhaps I've gotten used to using unintuitive software.
There are many many more but start with the app having the overbearing assumption that it thinks you want save to its file format rather than make an ad hoc edit.
I don't use Gimp as a 3D modeling software or a digital audio workstation. I use it to add text to a family photo. The primary storage medium is jpeg. I don't want or need anything else.
The real issues with Gimp start when you try to work with selections, transforms, cuts, crops and so on. Photoshop muscle memory doesn't transfer and it is so incredibly clunky.
So you open your photo, add your text, press Ctrl+E, choose a filename or press Enter to overwrite your old version, and press Enter to accept the default jpeg settings.
I guess it could save a couple of keypresses by auto-overwriting your original file without asking, or not asking about jpeg settings. But it doesn't seem like an outrageous workflow, considering that other people will want those options.
I do feel the same way as you about Photoshop muscle memory, having got quite good at it in the '90s and never really having caught up in Gimp.
But, as a long time but infrequent user, I really dislike the changes towards "non-destructive" UX that just seems to spawn endless layers and other forms of pixel buffer limbo that confuse me. Lately, it feels like I'm being slow walked by a passive-aggressive tool that wants to waste my time and mental energy.
I wish there was a "novice" or "casual" user setting option to go back to a much simpler UX, where I am operating immediately on the selected layer. Where a pasted object can be dragged but anchors as soon as I touch something else, etc. Where filters preview but then "apply" immediately. Where undo can revert some recent changes but otherwise the effects accumulate destructively into the current layer.
A naive user may never have to learn about layers, but they are still there when desired. I don't want a layer spawning on their own. I'll make the new layer before I start changing things, and I'll think deliberately how I want that layer filled. Then, I'll resume actions that immediately mutate it.
1) When you apply a filter, there's a "Merge filter" checkbox. If you check it, filters will be merged down immediately like in 2.10. The setting is remembered, though currently the unique Color filters are remembered separately from the generic ones.
2) If you go to Edit -> Keyboard Shortcuts and search for "Paste as Floating Selection", you can bind Ctrl + V to it so that you get the 2.10 floating selection behavior.
I sort of get their point. The "Only one of these formats(the one you have never heard of) will save all aspects of your work, every other one will lose things, pick wisely." school of interface design is a massive footgun. But I like interfaces that get out of your way and just let you do things.
And I just had a bright idea, "forget the save dialog, just use the export dialog for everything" but it turns out the export dialog will not let you save to .xcf My disappointment is immeasurable. Why not gimp team? You dashed my last hope for a single unified interface. Somebody had to go out of their way to take that out.
Then one day, they did it. They put the tools on the same window as the image, as Deluxe Paint did in 1985. FINALLY.
... but at the same time, they introduced the absolute bollocks that is "if you hit save we're going to spam you indefinitely into using our format".
In any other tool, if you _open_ a file (e.g. a PNG, JPEG, or in say LibreOffice's case, a CSV or XLSX), and then hit "save", it can nag you once that you're not using the tool's preferred file format, and _may_ be missing some important feature that only its preferred format supports... but you should just be able to click "fuck that, save it as the format I loaded it as" and not hear that again.
Not GIMP. It fucking well refuses to let you save as the format you opened. You have to cancel your "save" of the file you opened, and instead "export" to the file you opened... at which point it warns you you'll overwrite THE FILE YOU WANT TO SAVE. And after you've done that, and try to close the image, it'll warn you you haven't saved THE FUCKING FILE IT JUST FORCED YOU TO USE "EXPORT" TO SAVE because you didn't save it in its preferred format ABSOLUTELY GO FUCK YOURSELF, GIMP, I AM NOT GOING TO SAVE AS XCF A JPEG I AM CROPPING AND WILL NEVER EVER EDIT AGAIN
This is why I completely gave up on GIMP and will never open it again. I would like to line up all the GIMP authors in a row, and run down the line slapping them all in the face with a wet trout.
If anyone from GIMP is listening:
* User opens a non-native format, e.g. JPEG
* User hits "Save"
* Present user with a dialog like so:
This image may contain content that cannot be saved in the currently selected file format "JPEG"
Use the default XCF file format to be sure the image is saved correctly
[x] Ask when not saving in XCF or default format
[Use JPEG format] [Use XCF format]
* User can turn off this nag globally by deselecting "Ask when not saving in XCF or default format"
* If user selects "Use JPEG format", future saves of this file will not nag againThe big remaining thing I can think of is the "layer boundary" thing, which (it seems to me) is very confusing for new users and inconvenient for all users.
I also have a vibes-based feeling that when I used to use Photoshop twenty-five years ago I was a lot more productive than I'm able to be in GIMP, but I can't be sure if that's just because I used to do more graphic stuff back then and I've never picked it up to the same degree. I find myself having to hunt for things in menus a lot, but that might be a me problem. Photoshop also took a while to get used to.
Edit: I basically agree with the people complaining about Save and Export being unexpectedly separate, although also it's not that hard to press Ctrl+E instead of Ctrl+S.
That's the problem, you have a bias because you've already learned the tribal knowledge. Having to learn it from scratch, GIMP's UI is sorely lacking. While it does have the tools, the organization of them is all over the place.
The few times when I tried to use a recent version of Photoshop, however, I could not figure out even basic stuff like layer masks,
This made me chuckle.
The latest one I can recall is the canvas losing focus when you click anywhere outside it. So, to continue working after you interact with the layers panel e.g., you'll need to go through the extra step of reactivating the canvas.
I wasn't able to use the "move" tool to move a semi-transparent layer, it kept on switching my selection to the layer below it and moving that. That violated my expectation.
The solution was to use a modifier key, but it took me a while to find it.
Not going to say your expectation is wrong, I too almost always want the tool to operate on the selected layer rather than whatever layer has the pixels. But moving the layer with the pixels is not a bad default, it makes single click quick layer alignment moves possible.
Also, salutes, sort of unrelated, but your post made me look into quick selection based editing, And there are some good operations I have never used in there including alt to move the selection and ctrl + alt to move what is in the selection.
I enjoy Blender, but it's a specialist application with a highly complex, mostly unintuitive user interface that requires training and has a steep learning curve.
When people start using Blender, they generally start with a written or video tutorial series and are prepared to put in hours to get productive.
I'm sure Blender's UI is fine for what it does, but it's certainly not any easier to use than e.g. LightWave/Modo/Cinema4D was, and arguably harder.
Are people really saying GIMP is somehow harder than that?
From the very beginning it was trying to be an alternative to Photoshop, you know a software used by the professional industry, and 30 years later we are not sure it's any closer to that.
Whereas Blender is not just an alternative to Maya, 3DS Max and all the other options but might even be the leading software in its domain
Blender is still not beginner-friendly, but that's true of all 3D modeling software. There's a limit to how friendly you can make the UI without making it burdensome to accomplish things.
GIMP is just user-hostile, and deliberately so. GIMP's UI is not laid out logically, nor does its illogical UI make possible any additional functionality. The programming team has made such minimal effort to make the UI better that it's big news when they make even minor UI improvements.
For instance, we were repeatedly told that copy+paste creating a floating selection instead of a new layer was confusing and aggravating for users. So we changed it in 3.0 to make a new layer like other software. While we got praise from some people, we started getting new complaints that we'd broken people's workflow (see https://www.reddit.com/r/GIMP/comments/1vmrza2/it_is_not_str... for a wide range of user feedback as one example)
That doesn't mean we don't try to improve things (obligatory link to our user design feedback site: https://gitlab.gnome.org/Teams/GIMP/Design/gimp-ux/-/work_it...), but making big changes is difficult when you have an existing user base who are using your software successfully as-is.
GIMP has been catering to the extremely tiny niche of people who "successfully" use its software since at least the Slashdot days. And it's remained a niche product while all of its competitors in the opensource space have grown.
To your first point, it's difficult to know people's frame of reference online. I've listened to many complaints on forums, only to find out the person was thinking of older versions of GIMP and it no longer applied (like multi-window mode being default, outlining text being an ordeal, etc). We also see plenty of feedback like https://lemmy.world/post/50729195/25325527, so it's not always easy to figure what's universally illogical.
I'm not deflecting or saying that GIMP's UI is perfect the way it is - there's a lot of improvements I want to make to the non-destructive filter UI alone. But we can see that real people use the software for real work, so we try to keep existing users in mind when making UI improvements since it impacts them and what they do. There's been some well intentioned UI/UX requests I've implemented that ended up breaking a lot of people's workflows, and those still weigh on my soul. :)
(Obligatory plug for our UX tracker if you feel like providing specifics on UI problems you've encountered: https://gitlab.gnome.org/Teams/GIMP/Design/gimp-ux/-/work_it...)
I appreciate the backwards compatibility they highlight in the article, and more generally the ownership oss gives you over your files. My small business uses gimp, canva, and Inkscape, and they all have their purpose, but one of the complaints we have with canva is that it’s really hard to get the original files backed up somewhere, aside from canva itself. You have to download each file individually , which is quite a pain (please correct me if there’s an easier way!). Gimps openness is an obvious path for oss, but really is a great feature. If the gimp team stops, we’ll still be able to edit our gimp files. If the canva team stops, we mostly lose all the canva stuff.
Preparation for the future XCF (24.09.2023)
https://gitlab.gnome.org/GNOME/gimp/-/work_items/10076
Someone proposed newer ser-/deserialization approaches, but this didn't result in a discussion.
How even you do that without file fragmentation, zip doesn't exactly have defragment without complete file rewrite. Feels like if they want to have incremental changes SQLite would be better option as you can just VACUUM while file is not being accessed
It's still in-progress, so we'll have more technical details in the 3.3.2 release news.
Better Zipped XML than whatever monstrosity Adobe files are. PDF/PSD... shudder.
And Starcraft 2 data is just bunch of XML files.
But there's one material difference between StarCraft/Warcraft and Gimp: in Blizzard games, those were "zips" of heavy data files, notably read only data blobs. The game would read them, unpack in memory, and serve appropriately. Most of that data was key-value, text resources, or flat assets - images, sfx. With Gimp, we're talking highly structured data that's continuously being mutated. Very much not the best representation for that, even if you're just persisting it. They're only getting away with this because of SSDs - on spinning rust, you'd feel this.
(Also worth noting that, at least in StarCraft/SCBW, most of the files inside were custom, well-optimized binary formats. This predated the XML insanity of encoding data with 90%+ markup overhead.)
I meant zipping colloquially as in compressing an archive format. But you seem to get the gist of it ;)
> in Blizzard games, those were "zips" of heavy data files, notably read only data blobs. The game would read them, unpack in memory, and serve appropriately.
Not just game files but also the map format for Warcraft 3 was a glorified MPQ (source: https://867380699.github.io/blog/2019/05/09/W3X_Files_Format).
So whenever you edited a WC3 map, you were zipping the current map into an archive. Much like the GIMP example. Of course, WC3 didn't use as many XML files, though SC2 changed that.
I suddenly imagine a zip format with built-in git. Does this already exist?
Basically a file-format that has built-in history, rollback, logs etc. Enabling all these "zipped XML" formats to get this feature "for free".
Could be as simple as adding the .git to the zip and ensuring the software that writes the content to the zip also runs the correct git operations.
But could also be a simplified subset and adding git-ability to the (de)compress libs and bins, which can operate on the compressed .git. Simplified, because it won't need networking/remotes probably not even branches.
Quick edit: hmm, I'm already ~1 hour late, the relevant thread starts at https://news.ycombinator.com/item?id=49327457
OSTree, SQLite (single file DB), OCIRepository, git bundle. But it depends if you rather need code diffs or just versioning of large binary blobs (an image editor needs the latter).
// At this point, I'd like to take a moment to speak to you about the Adobe PSD format.
// PSD is not a good format. PSD is not even a bad format. Calling it such would be an
// insult to other bad formats, such as PCX or JPEG. No, PSD is an abysmal format. Having
// worked on this code for several weeks now, my hate for PSD has grown to a raging fire
// that burns with the fierce passion of a million suns.
// If there are two different ways of doing something, PSD will do both, in different
// places. It will then make up three more ways no sane human would think of, and do those
// too. PSD makes inconsistency an art form. Why, for instance, did it suddenly decide
// that *these* particular chunks should be aligned to four bytes, and that this alignement
// should *not* be included in the size? Other chunks in other places are either unaligned,
// or aligned with the alignment included in the size. Here, though, it is not included.
// Either one of these three behaviours would be fine. A sane format would pick one. PSD,
// of course, uses all three, and more.
// Trying to get data out of a PSD file is like trying to find something in the attic of
// your eccentric old uncle who died in a freak freshwater shark attack on his 58th
// birthday. That last detail may not be important for the purposes of the simile, but
// at this point I am spending a lot of time imagining amusing fates for the people
// responsible for this Rube Goldberg of a file format.
// Earlier, I tried to get a hold of the latest specs for the PSD file format. To do this,
// I had to apply to them for permission to apply to them to have them consider sending
// me this sacred tome. This would have involved faxing them a copy of some document or
// other, probably signed in blood. I can only imagine that they make this process so
// difficult because they are intensely ashamed of having created this abomination. I
// was naturally not gullible enough to go through with this procedure, but if I had done
// so, I would have printed out every single page of the spec, and set them all on fire.
// Were it within my power, I would gather every single copy of those specs, and launch
// them on a spaceship directly into the sun.
//
// PSD is not my favourite file format.Krita is not an image editor but a digital painting program. GIMP is a much more complete image editor despite its quirks.
(Also, currently our OpenRaster support is a plug-in that calls our PNG plug-in to do the rendering, so we'd have to rewrite it to be a core process if we wanted to use it as our main project file).
GIMP's UX is just bad. I loathe photoshop and desperately want to like GIMP, but each time I make the attempt the friction is too much and the workflows nonsensical. I used it a few weeks ago to place two images side by side in a larger canvas. It took half an hour in this mental little app to figure out how. I haven't have any issues with Inkscape and even Darktable ended up making sense. This is squarely a Gimp thing. Paraphrasing Kat Williams, "If people are calling you a crackhead for 20 years, you're smoking crack."
Thanks to all the contributors.
There’s something so pleasant about having GIMP around, efficient and so far removed from the disgusting greed that drives so many of the projects featured here.
Because I fail to see all the comments here as negative and unfounded. (and my guess why there is often negativity towards GIMP, is because it was too often advertised as a adequate Photoshop replacement, which it is not, so people got disappointed with it)
I know a lot of people don't like that but sometimes I feel that FOSS projects are intentionally sabotaging themselves by ignoring industry standard options/conventions and instead they are following open source ideas just to be different. GIMP is the perfect example of that and generally speaking UI/UX is the main symptom.
Blender was able to move forward by not listening to the FOSS crowd but to the industry. And see where are they now compared to GIMP.
Gimp was never in such a situation.
Culture is important.
Which brings us back to why so many people dislike Gimp, and/or see it as a posterchild example of bad FOSS alternatives.
I agree, and Culture IS important. And I think the culture around many Open Source "Alternatives" is harming themselves and the overall FOSS community. From Mastodon via Gimp to Nextcloud.
Blender is a very popular, maybe the most popular, for the tasks its used for. Gimp is not.
Not to mention the fact that if you ever mention in any way that GIMP's UX/UI could be better to anyone of its veteran devs they would turn weirdly ultra defensive and take everything personal.
[1] https://www.reddit.com/r/graphic_design/comments/rdtodb/adob...
It will lead to someone with the insight on how to make actual material improvements frustrated and angry that they don't have the technical skill (or time) to grapple with a complex codebase, and the people with the technical skill working on the codebase dismiss people with actual knowledge in different domains.
"Patches welcome" is not any kind of welcome. It's basically a euphemism for "fuck off, I don't want to have a conversation to make something better, I just want to hack on Feature X".
Yeh, this line is very common in that project that rhymes with chrome.
Meanwhile contributed features get stuck at "needs design team" for years.
Development to improve software should be a conversation between skilled and knowledgeable workers across many domains. Without that, you don't get improvement, you get feature creep.
"Patches welcome" is a conversation killer.
That said, if you have any kind of project (open source or not), and someone with significant experience in a domain outside your own makes a suggestion of something that could be improved, then the progressive and constructive response is "tell me why I should think that. What value is there in making this change? How will it be better" which opens up a dialogue, instead of "Hey man, RTFM and start coding" which is alienating (but your position is that there's actually nothing wrong with this. It is wrong if your goal is to create quality software).
I do design work sometimes, and when someone tells me "it doesn't look right", whether it's technically perfect or not, it means it's wrong. They might not be able to explain, but I know it's wrong somehow, and it's my responsibility to fix it. I don't sit them down in front of the keyboard and say "Ok, wiseguy, you fix it. You might need to take some classes at art school though". And sometimes that person is a designer and they say "Well, this composition is unbalanced, but you could try shifting that element a little to the right" and I'd be dumber than Trump if I didn't try that.
The subjectivity thing is interesting though. UX is not 99% subjective, and I don't know how you arrived at that figure. Start with Fitts Law, which is a thing, and not subjective and is measurable. Lots of people have spent a lot of time quantifying this stuff. There's science to it, and, yes, there's an irrational "feelings" component to it, but you ignore either or both at your peril.
Seems to have been working great for MS Office.
No offence to anyone, but I would not consider the performance of MS office to be great.
I guess it's comparative, but then I compare to its previous editions which used a sliver of the resources to accomplish 95% of what modern o365 does.
EDIT: Narrowed the date.
Well of course, but given that the previously employed technique was blitting, fliedumping memory areas, you can't be more efficient than that. Using XML is for transparency (readability).
(And, note, in context, I regard the ms office file format as lousy. The OpenOffice/LibreOffice format is good.)
Most of which is barely maintained and low quality.
For example, just recently:
https://linuxiac.com/libxml2-becomes-officially-unmaintained...
But even before it became officially unmaintained, it was already quite unloved, and it's one of the most used xml library.
We are not in the peak Java/J2EE era anymore. Pretty much nobody is going to willingly work on the foundations unless they're getting paid because the majority absolutely loathes XML and would not see maintaining XML libs as fun, and guess what, they're not? xslt also got removed from web browsers because nobody wants to maintain those libraries. And corporations like Google don't want to pay a dev for those either.
https://developer.chrome.com/docs/web-platform/deprecating-x...
Meanwhile the tooling around JSON is as healthy as it's ever been, with very efficient implementations in most common programming languages and multiple SIMD impls in C, C++, Rust etc. People actually want to work on this.
I don't understand why that is relevant; as long as there is a minimum level of tooling, libraries and support for their choice, what benefit would JSON bring over XML? I don't see a clear reason for one over the other.
Honestly, I'd have the same question if they chose JSON and someone asked why did they choose JSON over XML - Why wouldn't they?
How do they pronounce “XCF” such that it’s “a XCF file” and not “an XCF file”? “Xeceff”?
With “a” vs “an”, the pronunciation is more important than the spelling.
Similar to the name 'Herb' vs the vegetative 'herb'. A Herb vs an herb.
I know, hence my question about the pronunciation. If I had thought the spelling was more important, the “X” would have settled it so I wouldn’t have asked.
But yeah, in my mind, it's always been "ex see eff", so an XCF.