Rendered at 01:12:16 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
Liftyee 14 hours ago [-]
I don't get everyone's complaints about the interface. I've been using it for years, once you learn where things are I can get what I need done. The learning curve (finding where functions are, the right tools for each job, etc.) wasn't much different from other software like Blender or Darktable (or even Davinci Resolve).
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.
anfogoat 11 hours ago [-]
> Anyone enlighten me on actual usability problems
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.
barrkel 14 hours ago [-]
Export and Save As should be the same menu item with an option in the dialog.
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.
flufluflufluffy 14 hours ago [-]
That “overbearing assumption” is made by practically every other X-media editing app, for good reason — you can save your work and continue/revert stuff later. If all you’ve ever used is MS paint then I guess it’s an unexpected thing, but any other image/video editing app, digital audio workstation, 3D modeling software, etc… work exactly the same way. It would be unexpected to me if “save as” exported a flat file.
account42 12 hours ago [-]
Gimp doesn't save undo history in the XCF.
barrkel 12 hours ago [-]
I guess the idea is you can do edits via non-destructive layer effects and compositing a stack of layers, where somewhere amongst the stack is your original unmolested data. Though that has not been my experience with Gimp - it's far more likely to want to to commit to a rasterizing decision far earlier than Photoshop would.
barrkel 12 hours ago [-]
I don't care. 99% of my uses of an image editor are for ad hoc edits. I never want to clutter my disk with project files on the off-chance I want to preserve layers or whatnot. I have zfs snapshots and cloud backups should I want to revert but the odds I want to revert an ad hoc image edit are approximately nil - I can never recall needing to do so.
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.
saltcured 4 minutes ago [-]
I can empathize. I don't really care about the save vs export thing, as I have adapted to that and just go directly to export in the menu.
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.
Macha 12 hours ago [-]
Then Gimp is the wrong tool for you. You’re using a excavator to pull out weeds. Use Pinta or KolourPaint instead.
Joeboy 11 hours ago [-]
> I use it to add text to a family photo. The primary storage medium is jpeg. I don't want or need anything else.
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.
somat 7 hours ago [-]
I still think the original behavior where it just saves as whatever extension was entered as the name was one of the more enlightened ways to operate.
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.
mort96 13 hours ago [-]
The difference between exporting and saving is extremely important, and is something the user must understand in order to prevent data loss.
markstock 13 hours ago [-]
And Gimp users are not more likely to know that? It adds up to extra clicks for 90% of the images I load.
em-bee 12 hours ago [-]
how does the save/export distinction result in extra clicks? they are in the same menu right below each other. pick the right one. if you don't know you may pick the wrong one the first time, but after that you know. i find it faster than having to choose the format i want from a "save as" dialog
markstock 12 hours ago [-]
You just reminded me of a great feature that I think I first noticed in The Gimp: you don't have to search through the list of file types when exporting (I almost typed "saving"!), just type the extension in the file name and it'll save in that format! Love that part.
markstock 12 hours ago [-]
It's when I want to close the image or the application - the extra click to confirm that, yes, I am aware this image was not "saved" and that I could be losing data. I admit I have not looked into whether I can disable that extra notification.
em-bee 9 hours ago [-]
ok, fair point. i agree, that's a bit annoying. and ideally it should also tell whether changes are made after exporting.
itzprime 14 hours ago [-]
The learning curve certainly is a lot steeper than Photoshop or similar tools, and the GUI is very much counter intuitive compared to other graphics tools. Add that it lacked tons of nondestructive editing, smart objects etc. The poping out of different panels also get annoying super quick.
two_handfuls 8 hours ago [-]
> Anyone enlighten me on actual usability problems
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.
somat 6 hours ago [-]
It is also in the tool options control pane ( Pick layer or guide | move the selected layers).
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.
Joeboy 14 hours ago [-]
I'm a fairly casual / infrequent user, but they've already addressed most of the things I found infuriating in the past.
The 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.
jcarrano 12 hours ago [-]
Plus, it almost does not change between releases, so you need to learn it only once.
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,
reactordev 14 hours ago [-]
>"I don't get everyone's complaints about the interface. I've been using it for years..."
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.
LollipopYakuza 12 hours ago [-]
I have used Photosohop for almost 20 years, and then Affinity, Krita, and Gimp here and there.
In my opinion, it's a bit of both. At first I thought I was just used to Photoshop and I had to just accept losing productivity to make the switch.
But there something about Gimp UX that I can't get over, even though I can't really explain what is it. Of course fighting the muscle memory for all the features is a pain, but there's more. I can't find logic in the shortcuts, the menu organisation... I have not struggled as much for Krita or Affinity when I tried it.
account42 12 hours ago [-]
Are you sure that the problem isn't just that you have learned a different tribal knowledge (e.g. Photoshop) and now expect every image application to work that way?
reactordev 10 hours ago [-]
At no point did I mention myself or what programs I know.
heaney-555 12 hours ago [-]
>I don't get everyone's complaints about the interface. I've been using it for years
This made me chuckle.
amiga386 14 hours ago [-]
For decades, the tools panels floated separately from the image window, and the authors resolutely refused to put them in a single window.
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 again
m-p-3 1 hours ago [-]
It should attempt to save in the same file format originally used for single-layer or otherwise simple edits, and only use XCF if needed to retain the extra information that cannot be otherwise preserved.
aklemm 12 hours ago [-]
Honestly, this is fair.
7bit 14 hours ago [-]
[flagged]
nightfly 14 hours ago [-]
Calling people who are okay with different programs having different behavior _bootlickers_ is obnoxious
jake_and_fatman 13 hours ago [-]
[dead]
7bit 13 hours ago [-]
[flagged]
bobspoogeragi 14 hours ago [-]
[dead]
lightwords 15 hours ago [-]
You know what? The hate GIMP gets in the comments is entirely self-inflicted. Everyone praises Krita and Blender because their UIs are consistent and look good. GIMP, on the other hand, looks like a toddler worked on it: switches are huge compared to text, buttons and text have no padding and are squeezed together, and icons are oversized and scattered everywhere.
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.
nomilk 15 hours ago [-]
I once tried to use GIMP and gave up after 2 hours and got the task done in figma in 10 minutes. GIMP is a UX atrocity. The interface is a cluttered mess of meaningless panels and buttons. Worst for me is i'd spend 15 mins googling/reading how to do something, look for the corresponding buttons for 10 minutes, be unable to find them, and later discover they were on a panel that wasn't enabled by default (I didn't even know you had to enable panels; i'd assumed everything that was available was there in front of me). On macOS some panels randomly disappear behind other programs.
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.
jockm 9 hours ago [-]
GIMP still lags behind the photoshop I used in the late 90s/early 2000s. Then there is the name thing. I am *NOT* telling anyone else how to feel about it. I have no interest in relitigating it, but I am disabled and had it thrown at me as a term of hate; I just can't support a piece of software that uses it. We each have to stand up for what matters to us.
uurrnn 13 hours ago [-]
It's been like this forever. Always been "photoshop but harder to use".
consumer451 14 hours ago [-]
Friendly reminder to everyone that https://photopea.com exists. If you are used to Photoshop, then the UI will be quite familiar.
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.
It is an impressive piece of software, and there are lots of other low(er) cost alternatives to Photoshop; but I think the broad appeal of GIMP is that it it is free in the GPL sense of freedom, not just as in beer and that can't be ignored in any discussion of the software. Also the fact that you can use it fully offline
pessimizer 12 hours ago [-]
> I once tried to use GIMP and gave up after 2 hours and got the task done in figma in 10 minutes.
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.
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.
anfogoat 12 hours ago [-]
Thoughts on posting a UX and/or workflow related Issue under Teams/GIMP/Design/gimp-ux that would pretty much just recite an existing Issue from GNOME/gimp?
cmyk_student 12 hours ago [-]
One of our contributors does a lot of upkeep work, and he normally ports UX-related issues from the code tracker to the UX repo. Not 100% perfect, but it helps keep the focus in the right spot.
anfogoat 11 hours ago [-]
Am I reading this right in that I should avoid doing it myself then?
cmyk_student 10 hours ago [-]
If you think it's UX related concern, then I'd recommend posting it on the UX tracker first. But even if it's posted in the "wrong place", it'll likely be moved to the right one after it's looked at, if that makes sense?
However, if you see an older issue that could use some UX design discussion, feel free to suggest it be moved.
anfogoat 9 hours ago [-]
Alright, got it. Thanks
dist-epoch 13 hours ago [-]
Why not add a "Photoshop" theme? You select it in some option or on install, and it turns into something looking like Photoshop.
cmyk_student 13 hours ago [-]
We're working on an extension platform, and once that's up and running we'll probably reach out to PhotoGIMP developers (https://github.com/Diolinux/Photogimp) and see if they want to host it there.
Then people can easily download and install it directly in GIMP, hopefully making everyone happy.
pinkmuffinere 15 hours ago [-]
From tfa
> 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?
easyThrowaway 14 hours ago [-]
Between GIMP releases we saw entire graphics pipelines, conventions and workflows come and go. We had the Affinity suite, Canva, Paint.net, Clip Paint Studio, Sketch, various attempts from Adobe at expanding beyond the Photoshop ecosystem (Anyone remembers XD?), probably something else I’m missing right now. Now we’re in the age of Figma, with its own UI and quirks.
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.
TheChaplain 15 hours ago [-]
It could also be that the Gimp team and community wants their software a certain way, and I don't see why one should disrespect that?
Those who disagree are welcome to fork- and maintain it, if the users see value in it, they'll switch.
lightwords 15 hours ago [-]
It's just sad. Nobody wants to fork it because nobody uses GIMP, so forks get almost no traction. People love the effort and commitment, install it, try it for a couple of tasks, fail, and never come back. It has built up this reputation of being terrible, and no one wants to give it a second chance after their first impression.
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.
pessimizer 12 hours ago [-]
> People love the effort and commitment, install it, try it for a couple of tasks, fail, and never come back.
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.
gamblor956 9 hours ago [-]
If you just tried Photoshop 2 or 3 times, you'd fail to get anything accomplished either.
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.
whateveracct 7 hours ago [-]
? people take literal classes to learn Photoshop. I took a course at a rec center in high school in the 2000s and it had a bunch of adults learning it for work.
gamblor956 42 minutes ago [-]
In the early 2000s, people were taking classes to learn how to use Word. Now even grandma uses Word without thinking about it.
We're talking about 2026. GIMP had an excuse for its UI back in 1999. It doesn't anymore.
tkfoss 15 hours ago [-]
darktable is at least slowly actually getting better...
I like what blender managed to do.
kushalpandya 15 hours ago [-]
The attitude partly affects GNOME too, any time you'd constructively criticize it on places like their Issue tracker or r/gnome, their defenders would come with pitchforks at you. Glad I moved to KDE nearly a decade ago.
cromka 14 hours ago [-]
Gnome does UX and UI very well, though.
Macha 12 hours ago [-]
I honestly think a lot of the hate that GIMP gets is because as the first major FOSS image editor, people tried to use it for everything with a lot of square hole round peg situations.
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
BeFlatXIII 10 hours ago [-]
Finally, specific criticisms that aren’t “it’s not Photoshop!”
sho_hn 13 hours ago [-]
I don't understand the frequent comparisons to Blender at all, to be honest.
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?
haunter 12 hours ago [-]
>I don't understand the frequent comparisons to Blender at all, to be honest.
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
whywhywhywhy 10 hours ago [-]
Now imagine the world if the GIMP team had the epiphany the Blender team had a few years ago
pavel_lishin 10 hours ago [-]
What was their epiphany?
ProfessorLayton 8 hours ago [-]
Older Blender versions had terrible UX like Gimp does now, their epiphany was realizing that they should fix it.
gamblor956 9 hours ago [-]
Blender in the early days before the UI upgrade was like GIMP now: irrationally difficult to use.
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.
cmyk_student 9 hours ago [-]
The problem is that there's not just one "user". Tons of people have used GIMP for decades and are use to how it works - so changes to be less "user-hostile" can make it hostile to existing users.
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.
gamblor956 36 minutes ago [-]
Consider that the overwhelming majority of this thread on a tech-focused forum have issues with the UI. That should tell you something about how ridiculously illogical the UI is compared to every other program in the space.
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.
pinkmuffinere 14 hours ago [-]
Autosave sounds nice, I’m excited to have that!
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.
VCFundedGenYer 9 hours ago [-]
I wish I could enjoy GIMP but that interface is not easy to use. Krita is so much more intuitive and feels like FOSS Photoshop with little to no friction.
Someone proposed newer ser-/deserialization approaches, but this didn't result in a discussion.
cmyk_student 13 hours ago [-]
That someone is actually the maintainer of GIMP, and the person who is currently developing the new format (unless you mean one of the commenters, not the person who made the initial post).
kvemkon 11 hours ago [-]
I mean the one of the commenters, since the maintainer asked for comments.
time4tea 14 hours ago [-]
Zipped xml i wouldn't tbh. Its just not a great random access container. Compressed xml in a sqlite? Sure.
RugnirViking 13 hours ago [-]
Basically every complaint about GIMP is also valid for photoshop. People claiming PS is "intuitive" or "easy to use" literally just means they already know the keybindings/icons/quirks of photoshop specifically. It's okay! I have the exact same experience the other way around when I have to use photoshop
squidbeak 13 hours ago [-]
This isn't true. There have been plenty of other applications (Corel, Paint Shop Pro, Fireworks, Krita etc) with their own workflows and keybindings that weren't confusing for users.
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."
mimasama 17 hours ago [-]
Zipped XML? Isn't that just OpenRaster? (which is already supported by GIMP anyway, but also supported by Krita and other image editors)
cmyk_student 13 hours ago [-]
We didn't go into it in the news post, but one of the big benefits of this new format is that we can sync GeglBuffers (how pixel data is stored) automatically between GIMP and the new file. So you'll get fast auto-saves as you edit, which we couldn't do with OpenRaster. Also, the OpenRaster standard doesn't support all the features of GIMP/Krita (like non-destructive filters for instance).
(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).
Gualdrapo 16 hours ago [-]
> Krita and other image editors)
Krita is not an image editor but a digital painting program. GIMP is a much more complete image editor despite its quirks.
VCFundedGenYer 9 hours ago [-]
Disagree. I edit photos and make graphics all the time in Krita. You're splitting hairs.
mkl 13 hours ago [-]
Krita is good at editing images, so it is an image editor. It is also good at digital painting, and that's where much of its development focus lies.
Ygg2 17 hours ago [-]
It's not that weird. Most of Office and Open office formats are just zipped folders of XMLs.
Better Zipped XML than whatever monstrosity Adobe files are. PDF/PSD... shudder.
herrherrmann 17 hours ago [-]
Yep, even music software like Ableton Live is using zipped XML for the project files (although the much bigger audio files are stored independently in sub-folders). There were even efforts to use the XML format to manage Ableton project files with git in order to have a nicer change history (https://github.com/clintburgos/ableton-git).
berkes 16 hours ago [-]
> with git
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.
rzzzt 16 hours ago [-]
Involuntary reflex reply: ship an SQLite database as your data file?
> I suddenly imagine a zip format with built-in git. Does this already exist?
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).
Ygg2 16 hours ago [-]
I mean, zipping files in an archive and presenting them as a file is an ancient tradition in video games. For example Warcraft 3 used the MoPaQ archive to store data in .w3x file.
And Starcraft 2 data is just bunch of XML files.
TeMPOraL 16 hours ago [-]
Except MoPaQ weren't zips IIRC, they had their own clever format here - at least the OG StarCraft / SCBW MoPaQs were, playing with that is what I learned binary data handling on :). The idea of zipping data files applies, of course (and many a game used a literal ZIP with custom extension).
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.)
Ygg2 13 hours ago [-]
> Except MoPaQ weren't zips
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.
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.
herrherrmann 16 hours ago [-]
Cool, I didn’t know that! But makes a lot of sense.
// 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.
sho_hn 13 hours ago [-]
GIMP is excellent software. I've been using it at least every couple of days for 20+ years, and it's never once crashed or given me any kind of reliability issue, has always done the trick, and has been extremely resistant to enshittification. It's a reliable workhorse I'd always trust to insert into a workflow.
Thanks to all the contributors.
dm319 18 hours ago [-]
Non-destructive filter layers caught my eye, and has been something I've missed since moving off Windows/Photoshop to Linux. Looking around it seems like they introduced this in V3, which is great to see.
Balinares 17 hours ago [-]
Haven't those existed in Krita forever?
maya335 17 hours ago [-]
That is probably the V3 feature I'd notice most in daily use. Non-destructive editing makes experimentation much less costly; without it, every “maybe this looks better” becomes another layer or file copy.
bulgur999 17 hours ago [-]
As usual, whenever GIMP is involved, all we get are negative, often unfounded comments about an excellent piece of free software that is massively used and developed with very limited resources, doing its job really well.
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.
unpopularopp 17 hours ago [-]
I’m going to take the bait:
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.
ChrisGreenHeur 16 hours ago [-]
important here to remember that Blender was created within the industry as a commercial tool. When open sourced the leader of the project remained and knew quite well what separated a good creative tool from a bad one. It was always situated in a position where the core users were either hobbyists or professionals.
Gimp was never in such a situation.
Culture is important.
berkes 16 hours ago [-]
> 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.
graemep 16 hours ago [-]
Even the name is self sabotage.
BlackRing 15 hours ago [-]
It's a clever name. What's your beef with it?
drbscl 14 hours ago [-]
If I told my parents I'm "using GIMP", I will get some very concerned looks.
johannes1234321 14 hours ago [-]
It's a term often interpreted as derogatory for a group of people. (Disabled people)
ShadowOfThePit 13 hours ago [-]
What? How? GIMP is just some latex thing, what does it have to do with disabled people?
So GIMP has a larger user base than Blender, what is your point ?
Gualdrapo 15 hours ago [-]
I don't know what it has to do with anything - GIMP has been around for a while and has been the de facto FOSS alternative for photoshop for so long. That doesn't make that several of its UX and UI decisions are at least questionable nor make that comment you're replying any less true.
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.
graemep 16 hours ago [-]
Blender is something routinely recommend by normies. Gimp is not.
Blender is a very popular, maybe the most popular, for the tasks its used for. Gimp is not.
rplnt 16 hours ago [-]
Market share might be more relevant when we're comparing products with different market sizes.
igleria 16 hours ago [-]
I love that GIMP exists but... I have to say, it never got rid of the "backend developer doing frontend" feeling, and I've been aware of Gimp for 20 years now (did not know how to...ehem, run photoshop in my teens)
herrherrmann 17 hours ago [-]
… and the sizes of their updates are usually impressive! Seems to be a big project that is managed well to keep a good pace and keep the community in the loop. (Although I don’t know much about their inner workings.)
lukan 17 hours ago [-]
Do you have your special dark mode glasses on?
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)
dm319 16 hours ago [-]
It's a great piece of software. Best feature - not having your colours retrospectively removed from your project [1].
Photoshop is removing something that GIMP doesn't even have - PANTONE colors.
cmyk_student 11 hours ago [-]
We added import support for most Photoshop palette formats (ACB, ACO, ASE), so you can use them in GIMP. I don't think we can directly include Pantone palettes in the install because of copyright issues, but if you already have them, they should work fine in GIMP (and if not, let us know so we can fix it!)
account42 12 hours ago [-]
Not adding format features that you are not willing/able to maintain in perpetuity is a positive, yes.
rimliu 16 hours ago [-]
Yes, it is very pleasant to have it around. Especially when you switch to something else.
phendrenad2 16 hours ago [-]
Furthermore, it's free software. If people have a problem with it, they're free to show up and contribute, or fork if the community is really opposed to their ideas (they probably are for good reason, though).
MrVandemar 15 hours ago [-]
I can guarantee that anyone turning up and contributing or forking this project will not lead to the outcome of a improved piece of software.
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".
ChocolateGod 14 hours ago [-]
> "Patches welcome" is not any kind of welcome. It's basically a euphemism for "fuck off
Yeh, this line is very common in that project that rhymes with chrome.
Meanwhile contributed features get stuck at "needs design team" for years.
account42 12 hours ago [-]
So basically you want subordinates who work for you for free.
dvh 15 hours ago [-]
I just installed Ubuntu 26.04 and it's gimp starts for 14 seconds.
Joeboy 15 hours ago [-]
After the first run (where it has to evaluate plugins etc) it starts in under 4s on 26.04 on my Lenovo P53 (laptop from 2019). Which is admittedly not exactly snappy, but it's OK IMO.
dvh 8 hours ago [-]
This was my third run.
lopis 15 hours ago [-]
Is the Ubuntu version of GIMP distributed as a snap package? I've had horrible performance with snap apps.
HugoTea 13 hours ago [-]
It's lovely to see such a positive changelog combining the efforts of multiple foss developers, some of which are brand new contributors fixing bugs. Especially in this dark age of opensource closing contributions to defend against endless AI slop committers.
PunchyHamster 13 hours ago [-]
> The new project file format will follow a more common “zipped XML” structure. While the technical details are still being designed and implemented, this change will allow for faster saving since we’ll only need to update parts of the file instead of the whole thing each time.
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
cmyk_student 10 hours ago [-]
We didn't go into this in the news post since it was a quick overview, but GIMP uses GEGL for its main color and pixel engine. GEGL has a feature where you can automatically sync data between "buffers" in memory and in file - so as you're editing the image/layer/etc in GIMP, the buffers in the new format will automatically auto-save the data from the canvas.
It's still in-progress, so we'll have more technical details in the 3.3.2 release news.
account42 12 hours ago [-]
Yeah I'd also be worried about leaving invisible data in the file that the user has removed from the project.
roschdal 17 hours ago [-]
Zipped XML sounds like a bad idea. It's slow and bad. I say XCF forever.
EvanAnderson 17 hours ago [-]
SQLite would have been a lot better choice, in my opinion.
srvmshr 17 hours ago [-]
Pardon my ignorance about formats, but between XML & JSON, what would have made them choose XML? As I understand there is lot more tooling, standards & existing software examples around JSON for project & records management (e.g. VSCode's records as settings.json for example). Wasn't XML spearheaded by Microsoft but mostly used by Microsoft today?
cozzyd 17 hours ago [-]
json's only advantage is it's easier to write by hand, but that's not really a consideration here. XML has schema support and much more tooling available.
flgggd 13 hours ago [-]
> much more tooling available
Most of which is barely maintained and low quality.
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.
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.
lelanthran 16 hours ago [-]
> As I understand there is lot more tooling, standards & existing software examples around JSON for project & records management
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?
actionfromafar 16 hours ago [-]
JSON made me not hate XML. YAML made me not hate JSON.
Arainach 17 hours ago [-]
> It's slow and bad.
Seems to have been working great for MS Office.
dijit 17 hours ago [-]
“Great”.
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.
mdp2021 17 hours ago [-]
> previous editions... used a sliver of the resources
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.)
thaumasiotes 16 hours ago [-]
I don't think your parent comment was talking about the resources involved in saving a file, but rather the resources involved in running the software.
mdp2021 16 hours ago [-]
Thank you, probably so, but in that case I cannot see how said comment is consistent in the branch ("about file formats") - I do not get how it would follow.
graemep 15 hours ago [-]
Its very widely used. Perfomrance might not be great, but adoption is.
Ygg2 17 hours ago [-]
Office documents since the 2007 have used a zipped XML approach. Just take an .docx and open it in 7zip.
EDIT: Narrowed the date.
dijit 15 hours ago [-]
I’m aware. IIRC this was a response to Microsoft being forced to use some “open” protocol or something.
spider-mario 18 hours ago [-]
> For instance, we’re quite proud that a XCF file made by a small company for their logo in 1998 still renders the same way in the latest version of GIMP
How do they pronounce “XCF” such that it’s “a XCF file” and not “an XCF file”? “Xeceff”?
TeMPOraL 16 hours ago [-]
A "ksceef"?
But yeah, in my mind, it's always been "ex see eff", so an XCF.
cmyk_student 13 hours ago [-]
To be honest, I didn't think about it too hard - I just wrote "a XCF" because it doesn't start with a vowel. I don't think it's worth submitting an edit for, but you're welcome to consider it "an XCF".
ajcp 17 hours ago [-]
I find some word processors don't test for vowel sound, and only adhere to the actual vowel letter.
left-struck 17 hours ago [-]
In my mind it’s similar to exif
Choco31415 18 hours ago [-]
The beginning of “XCF” sounds similar to the beginning of “Exit”.
With “a” vs “an”, the pronunciation is more important than the spelling.
spider-mario 17 hours ago [-]
> With “a” vs “an”, the pronunciation is more important than the spelling.
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.
SwellJoe 17 hours ago [-]
You say "a exit"?
kbelder 8 hours ago [-]
There are words that some British accents pronounce with an initial consonant while Americans it with a vowel sound, so accordingly Brits use the 'a' article while Americans use 'an'. A case where accent changes the grammar of a sentence.
Similar to the name 'Herb' vs the vegetative 'herb'. A Herb vs an herb.
SwellJoe 8 hours ago [-]
So you pronounce it "a hexit" with a hard "h"?
bobspoogeragi 14 hours ago [-]
[dead]
socalgal2 18 hours ago [-]
[flagged]
ACCount37 17 hours ago [-]
Let's be honest, the real 1999 design would have been a custom binary format that happens to use the endian of the system it was developed on, and leaks bits and pieces of unflushed memory buffers whenever it writes to disk.
flohofwoe 17 hours ago [-]
No that would be an early 1990s file format ;)
1999 is exactly right for the start of the XML hype, everything had to be XML, it would single handedly solve the software crisis (after OOP failed to do that) because everything would be able to talk to everything!
falcor84 12 hours ago [-]
Well, they weren't quite wrong - it is an order of magnitude easier to reverse engineer an xml-based format than a binary one, especially now with LLMs.
anygivnthursday 16 hours ago [-]
Indeed, early 00s was still the SOAP XML era if I remember right, WSD, SOA, ...
reddalo 15 hours ago [-]
SOAP XML is so uselessly convoluted.
The whole Italian e-invoicing system is based on SOAP XML, and it's atrocious. They approved the specs in 2013, so it was already dated when it came out.
stuaxo 16 hours ago [-]
Jar
muhehe 18 hours ago [-]
What would you consider good modern design?
supriyo-biswas 18 hours ago [-]
SQLar[1], see [2] for some reasoning around why a database is preferred over zipped XML. Though, I'd be fine with a DBM-style database too as we only need the key-value part of it.
The problem with using database blobs for load/save is that you usually need a full database client in the application. SQlite advertises that use case, but it is complete overkill. You never need to run any sort of complex SQL query on an image file format for instance. Using XML+ZIP in this day and age is also a strange decision, but at least that way the data is inspectable with unzip, a text editor and an image viewer (assuming they use a standard image format to store the raw pixel data).
batmansmk 16 hours ago [-]
Think of Lightroom or automation over files. Many semi professionals from wedding photographers to designers want some form of batch automation and organization system over their files.
Several megabytes/gigabytes assets and you want to extract metadata, a preview, running as a batch some filter/compression/, conversion to CMYK, text injection ... fast partial read/write access would be nice.
Right now, most reads are performed through indexes because those files are slow to read.
If we take 10k sqlite files and want to retrieve a row, we would be around 3s on SSD, maintaining preemptive indexes become less important for a lot of use cases.
Change management and versioning also becomes quite efficient - sqlite can be configured to not offset bytes, so CVS like Epic Lore can efficiently delta the files and store minimal delta, or the file format itself can keep its edit history. Oh and it's 3x-10x less bytes without compressing the whole thing, so pages are stable through time.
About needing SQLite client, it's real but it's roughly the same size as an XML parser.
lentil_soup 15 hours ago [-]
> About needing SQLite client, it's real but it's roughly the same size as an XML parser.
what I like about it being XML is I can just open it with any text tool and inspect it. It's human readable so I can edit and debug it manually, no need to have a parser or an extra application just to see what's in my file
simonask 13 hours ago [-]
That's such an unbelievably niche use case for an image file format, though. Extremely the wrong thing to optimize for.
somat 15 hours ago [-]
Sqlite is probably overkill, you will probably never have actual relational data in an image format, But what it does bring to the table is a built in b-tree based storage, that is, you don't need to load the entire file into memory to edit it, in a prior age we would use Berkeley db for this. Sqlite in this role(a file format) is probably best thought of as a better superset of the berkleydb style key value store, more than one table per file and additional columns/indexes to keep metadata in.
Nothing wrong with XML, it is well understood, and the tooling is pretty good. But partial loads/edits is one thing it can not do.
lentil_soup 15 hours ago [-]
> Using XML+ZIP in this day and age is also a strange decision
I agree with you that SQlite is overkill but honestly curious to know why you think xml+zip is strange? what would you use instead?
TeMPOraL 17 hours ago [-]
> You never need to run any sort of complex SQL query on an image file format for instance.
Sure you will. Plenty of features that don't exist, or are implemented badly, because you can't easily do it.
Quick mental translation table: if you think "iterate over every ..." or a `for` loop, that's your SELECT query. If you think about `if` conditions, that's the parts that go after FROM clause.
x3ro 17 hours ago [-]
In order to have any advantage from this, you would have the added complexity of splitting your file format into tables that can be queried in a useful manner. However, for an image file format, you most likely need to hold the entire definition in memory at all times anyway. Assuming that’s the case, doesn’t XPath get you there most of the way (assuming XML), with _way_ less complexity?
TeMPOraL 16 hours ago [-]
Image data is just binary blobs. You aren't splitting that into channel columns or anything. But an image file for an editor like Gimp isn't one image blob. It's dozens or hundreds of them - one or more per layer - along with tons of associated metadata at every level.
All that tends to fit sensible schemas and managing it is what SQLite shines at.
x3ro 15 hours ago [-]
I don’t see how this addresses my point that zipped XML gives you the same thing, but simpler. I understand that a GIMP file is many images, so that makes a zip feel like a great fit to me. The only advantage I see for using a full-blown DB is ensuring consistency with references, which admittedly is a plus. But beyond that, what do you gain?
TeMPOraL 14 hours ago [-]
You're not:
- Continuously parsing and writing and reparsing text, 90% of which is useless (that's the JSON/S-expressions vs XML argument)
- Forcing a diverse relational structure to fit a tree hierarchy, hand-writing all the logic that manages representation change - either explicitly, at serialization boundary, or implicitly, in every single access operation you're doing to refer to some data;
- Or worse, using an off-the-shelf, generic object/XML mapper, in which case you just compound the bloat even more.
SQLite is one of the single most battle-tested and ubiquitous piece of software in the history of mankind. Anything "simpler" you're going to pick up is much more likely to be buggy and broken, and will definitely be orders of magnitude slower.
dist-epoch 13 hours ago [-]
SQLite has it's own issues - for example it doesn't support checksums. Quite bizarre for a database file format where integrity is supposedly highly valued. Saying it's the job of the filesystem doesn't help when all major OSes don't enable checksums in their default filesystem.
With a zip file at least you know your file was corrupted.
SQLite is fast, but it won't be faster than a hot loop in C. Having the loop construct dictated by the file format seems bad. For images it seems more reasonable to have them in-memory, except for huge image edge cases.
TeMPOraL 16 hours ago [-]
Images are the red herring. Pixel data is best read in hot loops in C, but that would be stored as blobs in SQLite anyway.
It's all the metadata around the image that's interesting. Images have layers, dozens or hundreds of them (this literally scales with how good your software is at handling those - the faster, and more powerful layer UX is, the more they get used). Some are pixel layers, other are effect layers, text layers, vector layers. Layers have metadata - names, sizes, colors, tags, types, special effects, and a bunch of other stuff I don't know because I don't use that 80% of features of GIMP/Photoshop/Affinity.
Then you have document level metadata, UI-specific metadata, etc. Also undo history. A lot of that is relevant to the work on images themselves, and changes in realtime, and can get even more useful if querying it wasn't such a PITA.
That - not the binary pixel blobs - is the selling case of using SQLite as application data format.
chungy 18 hours ago [-]
the SQLite archive format (it's probably worth linking to the main documentation[1], instead of the very old experimental repository) may not really be a good fit for something like GIMP's native file format. (To be clear, "SQLite archives" are not special compared to any other database: it's just a well-defined schema for an sqlar table, which the sqlite3 command line tool is able to create, update, and extract using syntax like the tar command.)
That being said, SQLite would still be a good choice, especially as it's a format that's really intended to be modified in-place, and has good data integrity features (eg: keep WAL enabled so that mid-save crashes/shutdowns don't corrupt your file), neither of which are provided by Zip. You could even just run zlib on data (be it XML or what have you) if optimizing the on-disk size of the file is desirable.
Compressed JSON with the binary content encoded in base64 strings, obviously.
berkes 15 hours ago [-]
So you compress a format that inflates binaries with 30%?
That not only ends up larger than "just the binary", it also eats a lot of extra CPU to (de)compress AND encode-decode.
This idea is novel, but wasteful.
(edit: I thought you were serious, so I answered serious. You were not ;)
speedgoose 15 hours ago [-]
Yes, this is not too rare to see base64 images in JSON but I won't recommend that.
You gain back most of the base64 overhead when you compress it though. It's slower but probably often worth it if the alternative is few more async HTTP queries that you would only fetch once.
einpoklum 17 hours ago [-]
Why would zipped JSON be fundamentally superior to zipped XML?
speedgoose 16 hours ago [-]
To answer seriously, my parent comment is a joke, JSON is a simpler format that maps better to most programming languages internal memory representations. Developers tend to prefer JSON’s simplicity over XML.
berkes 15 hours ago [-]
> most programming languages internal memory representations
Often heard wrt JSON but incorrect. It maps to the primitive types in JavaScript. But almost all programming languages treat floats and integers different, make distinction between char and strings and many have some form of date/time. JSON has neither.
In that direction, XML is much closer since every node is a triple (name, value, attributes) so can have type info, json is a tuple. And Protobuf, while not popular, gets this completely right.
speedgoose 15 hours ago [-]
I think it's too risky to treat numbers in JSON as something else than IEEE754 64bits floats. But yes, JSON is small and doesn't do datetimes, char, comments, and a million other things XML does.
But you don't need to think much about memory representation when you parse a JSON, and the developer experience is a lot more pleasing than browsing a XML tree. That what used to matter.
lelanthran 12 hours ago [-]
> JSON is a simpler format that maps better to most programming languages internal memory representations.
That's not been my understanding of it - it maps better to most programming language representations of dictionaries and arrays, but not the internal memory representations.
einpoklum 14 hours ago [-]
If this is intended for reading and writing by humans, then JSON doesn't cut it since you don't get comments (and perhaps also because of the weirdness of 64-bit floating-point values). Plus, XML is more "structurally nuanced". I suppose JSON is simpler to parse, but it's a trade-off of features, it's not like one is bad and the other is good.
elric 17 hours ago [-]
Welcome to 2026 unfounded hot takes.
Or less snarky: what's your gripe with zipped XML? It compresses reasonably well, has a useful structure, and has decades of mature tooling around it.
x3ro 17 hours ago [-]
Thanks! I had the exact same question for various of these posts here. I know these may be different groups of people, but I always see people advocating for simplicity, and zipped-XML is as simple as it gets, needs barely any extra dependencies (none in GIMP I assume), and is proven to work well (Word etc).
I also don’t understand why SQLite would be preferable here, considering you will likely also store large binary files alongside your document definition.. What does a db engine give me here?
OskarS 16 hours ago [-]
The obvious alternative is SQLite, and it has many advantages. If you want to do a "zipped list of files", SQLite does that just fine (that's what SQLar is), but it can do so much richer data. Even if you don't want that, it still offers resiliency that "zipped XML" can't match: if your software or computer crashes in the middle of saving your file, it'll almost certainly corrupt it. With SQLite, not an issue: all transactions are atomic, they either happen entirely or not at all.
I don't know what "mature tooling" you're talking about for zipped XML, but I guarantee you it's not going to be better (or more mature) than SQLite and its ecosystem.
hahahaa 15 hours ago [-]
Why XML bad?
MrVandemar 15 hours ago [-]
Fundamentally, it's not.
The problem was that people hyped it up as the solution for every problem and all the world's ills, so it wound up being used where it had no business being used (and therefore badly).
XML was a hammer used to bang in a lot of things that weren't remotely nail-shaped, and accordingly, a certain percentage of traumatised people despise it and react to any mention of it with fear and loathing.
It's kind of neat when you have an application for it that really leans into its strengths.
mattkevan 17 hours ago [-]
[flagged]
Jach 16 hours ago [-]
Also curious what you dislike so much. And how does Photoshop compare? https://i.ytimg.com/vi/_ghez_hKxeo/hq720.jpg I like the way Gimp has looked more and disliked many of their experiments changing things. The screenshot you linked isn't even the default look anymore, they've got a dreadful dark mode if you like that sort of thing. The first thing I do on a new install is restore the light mode and color icons it has, and make all the tool icons visible at once.
dash2 16 hours ago [-]
Your argument in favour of Gimp is that its default UI is dreadful? (I agree, but it's the fault of the Gimp UI, not of dark modes in general.)
Jach 16 hours ago [-]
I don't like its default look, but the screenshot they linked was non-default and what I do like, so I'm wondering why they find it sloppy/bad. Perhaps they would like Gimp's default more? Here's a representative shot from 2020: https://www.lifewire.com/thmb/H9QCFUVFrU035srbCoZ5erwS20Q=/1... Not even the +/- buttons another comment complains about are in this one.
enquirewithin 16 hours ago [-]
What do you want it to do?
I’ve used it, it works.
The handful of other things I’ve used that do the same thing or something similar are roughly the same.
All attempts at making the UI look better invariably obfuscated tools.
arewethereyeta 16 hours ago [-]
looks like the type of designs backend engineers do. Just throw everything in there
actionfromafar 16 hours ago [-]
Could you be very specific about what's sloppy? It would be very interesting to hear. I think I'm too numb from years of exposure.
dsego 16 hours ago [-]
Just look at the spacing and button layout, nothing is aligned, buttons are touching, the plus button is wider than the minus button, sizing is all over the place.
voidUpdate 16 hours ago [-]
> "Nothing is aligned"
The first two items in each row are aligned, and each item is aligned to one of two columns
> "Buttons are touching"
The only buttons that are touching are the + and - buttons which are part of the number input, as they are one connected part, and the units dropdown which is also part of the number selection in one item
dsego 12 hours ago [-]
Easier to answer with a screenshot, I added some annotations where things look messy.
- The icon theming is inconsistent. There's a group of black-and-white icons, a group of blue icons, and a group of colored icons. They are jumbled together and don't seem to indicate any kind of function.
- Tools are not functionally grouped in way which (to me) makes sense. Why is there no separation between "Select", "Adjust", and "Create" tools? Why is the color pipette not part of the color select thingy?
Tool options:
- Why does the Font selector have its label on top and to the right, rather than to the left?
- Why is there no spacing between the "+" of Size and the unit dropdown, like with the labels and the text selector right above?
- Why are window openers in the middle of text properties?
- Why do some options randomly have bold labels?
- Why are Hinting/Color/Style more to the right than the Justify options?
- Why does Color have a weird not-quite-rectangle with grey gaps, rather than reusing the design of the color selector in the toolbox?
- Why are there radio buttons for Justify, but dropdowns for Hinting, Style, and Box - despite them all having about the same number of options?
- Why do the options below Justify have icons rather than labels? Why is the first one using a different look and not visually centered with the other two?
- Why is the label for "Language" above the input field, rather than to the left of it?
Edit dialog on the screen:
- Why is the spacing between "backspace" and "bold" different from that between "bold"/"italic"/"underline"/"strikethrough"?
- Why is the spacing different from that between the font name and size?
- Why is there no spacing between font size and unit? Or, if they are a connected control, why are they not properly connected like -/+?
- Why is "reset to initial"(?) not a proper button?
- Why is the text size number field a different length than the other two? Do we expect people to enter 5-digit font sizes?
- Why does the gap to the right of "strikethrough" not match with anything?
So yes, I would say it is indeed a bit sloppy. There's probably another discussion to be had about its higher-level UX design, but (as a backend designer) this is the kind of stuff a backend developer ends up creating as a quick-and-dirty proof-of-concept before any of the front-end designers get involved.
It is functional, but definitely not enough effort went into making it good.
AltruisticGapHN 16 hours ago [-]
[flagged]
TiredOfLife 18 hours ago [-]
I thought every developer of this moved to the Glimpse fork
dspillett 17 hours ago [-]
That effort didn't last long. I think this is the first I've heard about it since inception, the repo (assuming this is the right one, https://github.com/joshgiesbrecht/Glimpse, it was the only GIMP related thing that came up amongst a sea of unrelated projects with the same name) is hasn't seen a commit in 7 years and what appears to be the official site away from a forge (https://getglimpse.app/about/) is currently unresponsive.
I don't want to revel in the fork's demise for any reason besides relief that it didn't end up splitting GIMP's contributors and community in a way that would have harmed both projects.
> we could not find contributors willing to step up and help with non-code tasks like moderating communication channels
Gotta say though it feels ironic that they couldn't find enough people to be comment janitors considering the whole thing was based on wanting people to stop saying a particular word.
> As a result, we struggled to scale the project to match increasing demand.
‘Glimpse didn't fail; it was actually too popular’?
ChocolateGod 17 hours ago [-]
That's the thing, they didn't take any GIMP contributors.
Everyone that was behind Glimpse was third party to the GIMP project.
pndy 16 hours ago [-]
This wasn't even a serious project but an example of malicious virtue signaling with a long-term plan for sort of hostile takeover. People involved just took the original code and replaced every GIMP occurrence with Glimpse, added new logo/icon and called job done. Then went to the news sites trying to raise awareness of the supposed name controversy hoping noise will discredit GIMP while they'll portrait themselves as the saviors. Because who'd want to contribute to a software that has such bad reputation.
It's been over 24 years for me since I've used GIMP for the first time and the only problem that I had was always with GUI ergonomics. You had to understand everything anew after being more accustomed to proprietary software pieces. My friend never adapted to anything else but Photoshop - even Krita is beyond her abilities.
Nearly every discussion regarding GIMP on hn will include thread about the name 'problem' and this is getting tiresome. The name won't change and those who feel offended should focus on problems whose solution is genuinely productive.
ChocolateGod 16 hours ago [-]
> This wasn't even a serious project but an example of malicious virtue signaling with a long-term plan for sort of hostile takeover. People involved just took the original code and replaced every GIMP occurrence with Glimpse
I recall one of the reasons given on the GIMP Gitlab issue to change the name was "it will encourage more contributors" that apparently don't contribute because of the project name. Glimpse certainly had a lot of contributors... not.
I can't think of a single project that changed a name to satisfy these people ever received more contributors as a result.
Lammy 16 hours ago [-]
I feel like it would have though if Glimpse had managed to become the default image editor on at least one major distro, just by virtue of people stumbling in to contributing some fix or addition to ‘the thing that came with my OS’ without necessarily being aware of the history.
Like the FFmpeg/libav fork that eventually got back together. Or Compiz/Beryl, or Emacs/XEmacs, or GCC/EGCS, or whatever :)
ben_w 18 hours ago [-]
I'm surprised it got that epithet, I'm used to "upset by weird sex stuff" as being a US-right position, and "woke" being a term that's used by US-right to denigrate US-left.
Then again, I'm also old enough to have seen it shift significantly in meaning at least once, and I think I'm seeing it shift meaning again.
SwellJoe 17 hours ago [-]
Before the weird sex stuff, "gimp" was an insulting term for a crippled person. The fact that it's so long out of common use for that purpose that a lot of folks don't realize that is perhaps an argument for not taking it too seriously. On the other hand, disabled folks are certainly among the most oppressed and abused and in ways that aren't well-understood by most folks, so a decent person should be pretty careful about using language that could be demeaning. I dunno. It feels like an archaic term that ought not have any power today, but what do I know?
ChocolateGod 17 hours ago [-]
> Before the weird sex stuff, "gimp" was an insulting term for a crippled person. The fact that it's so long out of common use for that purpose that a lot of folks don't realize that is perhaps an argument for not taking it too seriously
It's a US specific slur when used in this context, not in other English speaking countries (let alone non-English countries) A lot of GIMP developers are European yet the Glimpse project tried to force American cultural/linguistic rules on a non-American project.
Words mean different things in different regions and languages, just because it's offensive in your language does not mean it's offensive in others.
SwellJoe 17 hours ago [-]
They didn't try to force anybody to do anything. They forked a Free Software project as allowed by the license. You seem awfully sensitive.
ChocolateGod 16 hours ago [-]
I remember the (now deleted) Gitlab issue on the GIMP project that called on for the name to change, it certainly wasn't friendly.
SwellJoe 15 hours ago [-]
What do you believe the word "force" means?
amon_spek 15 hours ago [-]
It's a decorative strip of fabric used to trim upholstery and hide tacks to me.
SwellJoe 7 hours ago [-]
Somehow, I doubt you're an upholsterer.
TeriyakiBomb 17 hours ago [-]
In the UK, it’s the sex one and would be used as a general “idiot” word but that seemed to have mostly faded away. It’s not a word I’ve seen used in that context for many years.
Not refuting anything here, just adding some context from over here. Whichever way you slice it, it’s always been an awful name.
SwellJoe 17 hours ago [-]
Yeah, it's always felt like an "edgy" name a teenager or quite young man would come up with. Which makes sense, the original GIMP authors were college-aged boys when they created it.
I'd like it if they changed the name. We're (the Open Source community) not teenagers or annoying college kids anymore, by and large.
maybewhenthesun 16 hours ago [-]
I like it that the scruffy teenager hacker mentality is preserved in the name. It was also a bit of self deprecating humour at the time, because using Gimp instead of Photoshop did make you feel crippled a bit.
I hope they never give in to the corporate-lawyer induced bland-washing .
SwellJoe 15 hours ago [-]
I'm not a corporate lawyer.
I'm just a Free Software user and developer and I think it's nicer when I can recommend something to someone without having to think about whether I might be saying something rude or hurtful. I assume there was a stink about the name because it bothers some disabled folks. It's not my place to tell them not to be bothered, I'd rather just not do the shitty thing that bothers them.
It seems cringey and childish to insist on doing a thing that makes a bunch of people feel unwelcome based on something about themselves they can't change. And, for what? So you can feel like a scruffy teenaged hacker?
I like my Free Software community to welcome people of all sorts.
TeriyakiBomb 15 hours ago [-]
Having a "stink" is right. Even without much thought, it's off-putting, does not sound professional and really icky. When you think a bit harder, it's just kinda awful. I do actually suspect the name does have some measurable impact on adoption. Most people don't want to say "I gave up photoshop, I use gimp." outside of hardcore linux circles and since then, it has gone from the only open source gig in town to just one of many alternatives.
____mr____ 16 hours ago [-]
The issue is that there are a bunch of people like this[0] who get incredibly upset and politicize any attempts to be "the adult in the room" and ask for renaming of unsavory names.
The funniest of these is when Europeans talk about how they are being "forced" to comply with American cultural norms and you go through their account and they are so deeply steeped in American culture due to their participation in the anglophone internet spaces which are dominated by them. People in Europe will argue with you that you are importing woke culture if you suggest that they shouldn't say the N word, but are seemingly completely oblivious to the fact that the reason they find the word exciting to say and they say it in English is an import of American culture
Really? In Northern Ireland in the 80s/90s it was always used in the same way as spaz / flid etc - ie. an ableist slur. Kids would typically scream it when someone did something clumsy or uncoordinated. Lovely, eh?
I don't think I've actually heard the sex thing being used anywhere in the UK, except perhaps when discussing Pulp Fiction. Even in kink contexts!
SwellJoe 8 hours ago [-]
A lot of kink participants are sensitive to oppressive language and try not to use it (outside of a consensual scene that includes it, perhaps). Consent culture is necessarily a culture that doesn't use slurs in daily public life, and at least some who participate in kink are particularly careful about consent.
Lammy 17 hours ago [-]
Personally I just prefer to avoid the debate and call it “GNU IMP” v(._. )v
kbelder 8 hours ago [-]
That's probably the best solution.
I think they could also get away with "gImp"
Or even, take after GIF and pronounce it with a "J" sound, like "JIMP"
herbst 9 hours ago [-]
It could be that easy
actionfromafar 16 hours ago [-]
Maybe this is the way forward? :)
herbst 9 hours ago [-]
I honestly didn't put that much thought into it. I assumed it's woke as it opposed the sexual name, from my short Google fo this was the main reason for the fork.
I am not American either so I had no idea about the "old meaning" and even less do I care about sexual stuff in my software naming schemes.
curtisblaine 17 hours ago [-]
[dead]
amelius 14 hours ago [-]
They should make it easy to install and use GenAI plugins (without messing with GPU drivers, etc.)
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.
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.
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.
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.
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.
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.
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.
The 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.
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,
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.
This made me chuckle.
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:
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:
https://news.ycombinator.com/item?id=33334521
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.
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.
However, if you see an older issue that could use some UX design discussion, feel free to suggest it be moved.
Then people can easily download and install it directly in GIMP, hopefully making everyone happy.
> 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.
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.
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
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.
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.
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."
(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).
Krita is not an image editor but a digital painting program. GIMP is a much more complete image editor despite its quirks.
Better Zipped XML than whatever monstrosity Adobe files are. PDF/PSD... shudder.
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).
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.
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.
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.
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.
Blender is a very popular, maybe the most popular, for the tasks its used for. Gimp is not.
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)
[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.
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.
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?
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.
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.)
EDIT: Narrowed the date.
How do they pronounce “XCF” such that it’s “a XCF file” and not “an XCF file”? “Xeceff”?
But yeah, in my mind, it's always been "ex see eff", so an XCF.
With “a” vs “an”, the pronunciation is more important than the spelling.
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.
Similar to the name 'Herb' vs the vegetative 'herb'. A Herb vs an herb.
1999 is exactly right for the start of the XML hype, everything had to be XML, it would single handedly solve the software crisis (after OOP failed to do that) because everything would be able to talk to everything!
The whole Italian e-invoicing system is based on SOAP XML, and it's atrocious. They approved the specs in 2013, so it was already dated when it came out.
[1] https://sqlite.org/sqlar/doc/trunk/README.md
[2] https://www.sqlite.org/affcase1.html
Several megabytes/gigabytes assets and you want to extract metadata, a preview, running as a batch some filter/compression/, conversion to CMYK, text injection ... fast partial read/write access would be nice. Right now, most reads are performed through indexes because those files are slow to read.
If we take 10k sqlite files and want to retrieve a row, we would be around 3s on SSD, maintaining preemptive indexes become less important for a lot of use cases.
Change management and versioning also becomes quite efficient - sqlite can be configured to not offset bytes, so CVS like Epic Lore can efficiently delta the files and store minimal delta, or the file format itself can keep its edit history. Oh and it's 3x-10x less bytes without compressing the whole thing, so pages are stable through time.
About needing SQLite client, it's real but it's roughly the same size as an XML parser.
what I like about it being XML is I can just open it with any text tool and inspect it. It's human readable so I can edit and debug it manually, no need to have a parser or an extra application just to see what's in my file
Nothing wrong with XML, it is well understood, and the tooling is pretty good. But partial loads/edits is one thing it can not do.
I agree with you that SQlite is overkill but honestly curious to know why you think xml+zip is strange? what would you use instead?
Sure you will. Plenty of features that don't exist, or are implemented badly, because you can't easily do it.
Quick mental translation table: if you think "iterate over every ..." or a `for` loop, that's your SELECT query. If you think about `if` conditions, that's the parts that go after FROM clause.
All that tends to fit sensible schemas and managing it is what SQLite shines at.
- Continuously parsing and writing and reparsing text, 90% of which is useless (that's the JSON/S-expressions vs XML argument)
- Forcing a diverse relational structure to fit a tree hierarchy, hand-writing all the logic that manages representation change - either explicitly, at serialization boundary, or implicitly, in every single access operation you're doing to refer to some data;
- Or worse, using an off-the-shelf, generic object/XML mapper, in which case you just compound the bloat even more.
SQLite is one of the single most battle-tested and ubiquitous piece of software in the history of mankind. Anything "simpler" you're going to pick up is much more likely to be buggy and broken, and will definitely be orders of magnitude slower.
With a zip file at least you know your file was corrupted.
https://avi.im/blag/2024/sqlite-bit-flip/
It's all the metadata around the image that's interesting. Images have layers, dozens or hundreds of them (this literally scales with how good your software is at handling those - the faster, and more powerful layer UX is, the more they get used). Some are pixel layers, other are effect layers, text layers, vector layers. Layers have metadata - names, sizes, colors, tags, types, special effects, and a bunch of other stuff I don't know because I don't use that 80% of features of GIMP/Photoshop/Affinity.
Then you have document level metadata, UI-specific metadata, etc. Also undo history. A lot of that is relevant to the work on images themselves, and changes in realtime, and can get even more useful if querying it wasn't such a PITA.
That - not the binary pixel blobs - is the selling case of using SQLite as application data format.
That being said, SQLite would still be a good choice, especially as it's a format that's really intended to be modified in-place, and has good data integrity features (eg: keep WAL enabled so that mid-save crashes/shutdowns don't corrupt your file), neither of which are provided by Zip. You could even just run zlib on data (be it XML or what have you) if optimizing the on-disk size of the file is desirable.
[1] https://sqlite.org/cli.html#sqlite_archive_support
Not really a great option for an image format, where we therefore can't have multiple implementations. Unless I misremembered.
That not only ends up larger than "just the binary", it also eats a lot of extra CPU to (de)compress AND encode-decode.
This idea is novel, but wasteful.
(edit: I thought you were serious, so I answered serious. You were not ;)
You gain back most of the base64 overhead when you compress it though. It's slower but probably often worth it if the alternative is few more async HTTP queries that you would only fetch once.
Often heard wrt JSON but incorrect. It maps to the primitive types in JavaScript. But almost all programming languages treat floats and integers different, make distinction between char and strings and many have some form of date/time. JSON has neither.
In that direction, XML is much closer since every node is a triple (name, value, attributes) so can have type info, json is a tuple. And Protobuf, while not popular, gets this completely right.
But you don't need to think much about memory representation when you parse a JSON, and the developer experience is a lot more pleasing than browsing a XML tree. That what used to matter.
That's not been my understanding of it - it maps better to most programming language representations of dictionaries and arrays, but not the internal memory representations.
Or less snarky: what's your gripe with zipped XML? It compresses reasonably well, has a useful structure, and has decades of mature tooling around it.
I also don’t understand why SQLite would be preferable here, considering you will likely also store large binary files alongside your document definition.. What does a db engine give me here?
I don't know what "mature tooling" you're talking about for zipped XML, but I guarantee you it's not going to be better (or more mature) than SQLite and its ecosystem.
The problem was that people hyped it up as the solution for every problem and all the world's ills, so it wound up being used where it had no business being used (and therefore badly).
XML was a hammer used to bang in a lot of things that weren't remotely nail-shaped, and accordingly, a certain percentage of traumatised people despise it and react to any mention of it with fear and loathing.
It's kind of neat when you have an application for it that really leans into its strengths.
I’ve used it, it works.
The handful of other things I’ve used that do the same thing or something similar are roughly the same.
All attempts at making the UI look better invariably obfuscated tools.
The first two items in each row are aligned, and each item is aligned to one of two columns
> "Buttons are touching"
The only buttons that are touching are the + and - buttons which are part of the number input, as they are one connected part, and the units dropdown which is also part of the number selection in one item
https://imgur.com/a/95j7tgQ
- The icon theming is inconsistent. There's a group of black-and-white icons, a group of blue icons, and a group of colored icons. They are jumbled together and don't seem to indicate any kind of function.
- Tools are not functionally grouped in way which (to me) makes sense. Why is there no separation between "Select", "Adjust", and "Create" tools? Why is the color pipette not part of the color select thingy?
Tool options:
- Why does the Font selector have its label on top and to the right, rather than to the left?
- Why is there no spacing between the "+" of Size and the unit dropdown, like with the labels and the text selector right above?
- Why are window openers in the middle of text properties?
- Why do some options randomly have bold labels?
- Why are Hinting/Color/Style more to the right than the Justify options?
- Why does Color have a weird not-quite-rectangle with grey gaps, rather than reusing the design of the color selector in the toolbox?
- Why are there radio buttons for Justify, but dropdowns for Hinting, Style, and Box - despite them all having about the same number of options?
- Why do the options below Justify have icons rather than labels? Why is the first one using a different look and not visually centered with the other two?
- Why is the label for "Language" above the input field, rather than to the left of it?
Edit dialog on the screen:
- Why is the spacing between "backspace" and "bold" different from that between "bold"/"italic"/"underline"/"strikethrough"?
- Why is the spacing different from that between the font name and size?
- Why is there no spacing between font size and unit? Or, if they are a connected control, why are they not properly connected like -/+?
- Why is "reset to initial"(?) not a proper button?
- Why is the text size number field a different length than the other two? Do we expect people to enter 5-digit font sizes?
- Why does the gap to the right of "strikethrough" not match with anything?
So yes, I would say it is indeed a bit sloppy. There's probably another discussion to be had about its higher-level UX design, but (as a backend designer) this is the kind of stuff a backend developer ends up creating as a quick-and-dirty proof-of-concept before any of the front-end designers get involved.
It is functional, but definitely not enough effort went into making it good.
> we could not find contributors willing to step up and help with non-code tasks like moderating communication channels
Gotta say though it feels ironic that they couldn't find enough people to be comment janitors considering the whole thing was based on wanting people to stop saying a particular word.
> As a result, we struggled to scale the project to match increasing demand.
‘Glimpse didn't fail; it was actually too popular’?
Everyone that was behind Glimpse was third party to the GIMP project.
It's been over 24 years for me since I've used GIMP for the first time and the only problem that I had was always with GUI ergonomics. You had to understand everything anew after being more accustomed to proprietary software pieces. My friend never adapted to anything else but Photoshop - even Krita is beyond her abilities.
Nearly every discussion regarding GIMP on hn will include thread about the name 'problem' and this is getting tiresome. The name won't change and those who feel offended should focus on problems whose solution is genuinely productive.
I recall one of the reasons given on the GIMP Gitlab issue to change the name was "it will encourage more contributors" that apparently don't contribute because of the project name. Glimpse certainly had a lot of contributors... not.
I can't think of a single project that changed a name to satisfy these people ever received more contributors as a result.
Like the FFmpeg/libav fork that eventually got back together. Or Compiz/Beryl, or Emacs/XEmacs, or GCC/EGCS, or whatever :)
Then again, I'm also old enough to have seen it shift significantly in meaning at least once, and I think I'm seeing it shift meaning again.
It's a US specific slur when used in this context, not in other English speaking countries (let alone non-English countries) A lot of GIMP developers are European yet the Glimpse project tried to force American cultural/linguistic rules on a non-American project.
Words mean different things in different regions and languages, just because it's offensive in your language does not mean it's offensive in others.
Not refuting anything here, just adding some context from over here. Whichever way you slice it, it’s always been an awful name.
I'd like it if they changed the name. We're (the Open Source community) not teenagers or annoying college kids anymore, by and large.
I hope they never give in to the corporate-lawyer induced bland-washing .
I'm just a Free Software user and developer and I think it's nicer when I can recommend something to someone without having to think about whether I might be saying something rude or hurtful. I assume there was a stink about the name because it bothers some disabled folks. It's not my place to tell them not to be bothered, I'd rather just not do the shitty thing that bothers them.
It seems cringey and childish to insist on doing a thing that makes a bunch of people feel unwelcome based on something about themselves they can't change. And, for what? So you can feel like a scruffy teenaged hacker?
I like my Free Software community to welcome people of all sorts.
The funniest of these is when Europeans talk about how they are being "forced" to comply with American cultural norms and you go through their account and they are so deeply steeped in American culture due to their participation in the anglophone internet spaces which are dominated by them. People in Europe will argue with you that you are importing woke culture if you suggest that they shouldn't say the N word, but are seemingly completely oblivious to the fact that the reason they find the word exciting to say and they say it in English is an import of American culture
[0]. https://news.ycombinator.com/item?id=49327771
I don't think I've actually heard the sex thing being used anywhere in the UK, except perhaps when discussing Pulp Fiction. Even in kink contexts!
I think they could also get away with "gImp"
Or even, take after GIF and pronounce it with a "J" sound, like "JIMP"
I am not American either so I had no idea about the "old meaning" and even less do I care about sexual stuff in my software naming schemes.