GIMP 3.2 released(gimp.org) |
GIMP 3.2 released(gimp.org) |
This plugin https://github.com/LinuxBeaver/Gimp_Layer_Effects_Text_Style... also makes adding text effects with GIMP pretty good. This is unrelated to 3.2 but turned out to be a necessity for me.
We were hoping to expand that feature to all layer types for 3.2, but we ran out of time to properly test it for release. It'll like be finished for the next minor release.
Maybe it's because I grew up with Paint Shop Pro 6 and such, but that seems completely normal and expected to me
I'm honestly baffled at your surprise... say, if you crop an image, and 2 seconds later you enlarge it to its original size; do you expect to get the inital image back? Or a uniform color padding around your crop?
Scaling is just cropping in the frequency domain. Behaviour should be the same.
Of course as a developer that makes it all the more impressive - kudos to the team for making such big progress, I can't wait to play around with all the new improvements!
I get the practical benefits of it, but it feels shoehorned in to an interface for doing destructive edits. Chained edits frequently interact in ways that confuse/surprise me.
I think I'd rather do non-destructive edits via some sort of node-editor interface. (And to be honest most of the things I use GIMP for don't need non-destructive editing in the first place)
You can check "Merge filter" at the bottom of the filter dialogue though, and it will automatically merge the filter like in 2.10 (and the setting is remembered going forward)
I get it, and when Photoshop changed this default, GIMP followed with changing this workflow. It used to be different in older versions of Photoshop and Gimp.
Advanced user usually know exactly what they're doing, and opening a PNG or JPEG file, changing a few pixels, and saving it, should require as few key presses as possible.
I don't want the UI to get in my way when I open->edit->save.
Edit → Keyboard Shortcuts → file → Overwrite […]
It might just be that it’s better tailored for graphic designers, which I’m clearly not. But now I can’t even figure out how to draw a square on screen. Let along anything clever.
We get an equal amount of "GIMP's UI never changes!" and "You changed too much of the UI in the latest version", so it's difficult sometimes to figure out the specific issues.
Albeit I might only use it, at most, for a few hours every few months. So I’m definitely not a seasoned expert despite that length of time. But I always considered myself reasonably competent.
I usually indifferent about UI changes, I’m not someone who tends to complain either for nor against. So this isn’t a complaint about Gimp changing thing (if that’s what happened). The issue here is really more about how I now cannot figure out the simple things any more. And that might just be on me rather than Gimp.
I agree it's a bit counter-intuitive, but afaik it's always worked like that.
Also small world, floating point JPEG person here.
Didnt know that! Thanks for telling!
There are hundreds of good reasons why someone might want to overlay a vector shape on a bitmap image. The desire to draw shapes on bitmap isn’t something weird that I’ve just invented for HN. It’s been a staple feature such graphics packages since the inception of bitmap graphics editing. And it’s been a staple feature of Gimp since I first switched to Linux in the 90s.
But that’s all moot because I was just making an arbitrary example.
And as an aside, I do use vector drawing software too. So I’m fully aware of their existence.
Once you export it is, of course, actually downscaled.
Same idea behind masks and modifiers and the like. Most modern creation tools try to give ample opportunity for non-destructive modification to simpler, immutable primitive layers.
When saving, it simply should say "Exporting pic.jpg".
We don't want to take away choices - we just want to add more options for people's workflows.
From a user perspective I wouldn't like it, if I were to crop something and the data would be still there afterwards. That would be a data leak waiting to happen.
What percentage of users sends around raw project files from which they've cropped out sensitive data to users who shouldn't see that data, vs. what percentage of users ever wants to adjust the crop after applying other filters? The latter is basically everyone, the earlier I'm guessing at most 1%?
going by your text editor analogy, we are arguing against implementing undo/redo as a "non-destructive delete", based on adding backspace control characters within the text file. I want infinitw undo/redo, but i also want that when I delete a character it is really gone, not hidden!
Half the developers I know still don't use LSP (and they're not necessarily older devs), and even the full-time developers in my circle resist their bosses forcing Copilot or Claude down their throats and use in fact 0 AI. Living in France, i don't know a single developer using AI tools, except for drive-by pull-request submitters i have never met.
I understand the world is nuanced and there are different dynamics at play, and my circles are not statistically representative of the world at large. Likewise, please don't assume this literally world-eating fad (AI) is what "most of us" are doing just because that's all the cool kids talk about.
It would be a true shame if every useful feature was left out due to 1% of use cases becoming slightly different.
Your IDE either uses an LSP or has its own baked-in proprietary version of a LSP. Nobody, and I mean nobody, working on real projects is "raw dawgin" a text file.
Most modern IDE's support smart auto-complete, a form of AI assistance, and most people use that at a minimum. Further, most IDE's do support advanced AI assisted auto-complete via copilot, codex, Claude or a plethora of other options - and many (or most) use them to save time writing and refactoring predictable, repetitive portions of their code.
Not doing so is like forgoing wheels on your car because technically you can just slide it upon the ground.
The only people I've seen in the situation you've described are students at university learning their first language...
I write code exclusively in vim. Unless you want to pretend that ctags is a proprietary version of an LSP, I'm not using an LSP either. I work at a global tech company, and the codebase I work on powers the datacenter networks of most hyperscalers. So, very much a real project. And I'm not an outlier, probably half the engineers at my company are just raw dawgin it with either vim or emacs.
Using a text editor without LSP or some form of intellisense in 2026 is in the extreme minority. Pretending otherwise is either an attempted (and misguided) "flex" or just plain foolishness.
> probably half the engineers at my company are just raw dawgin it with either vim or emacs
Both vim and emacs support LSP and intellisense. You can even use copilot in both. Maybe you're just not aware...
Your ai-powered friends and colleagues are not statistically representative. The world is nuanced, everyone is unique, and we're not sociologists running a long study about what "most of us" are doing.
> forgoing wheels on your car
Now you're being silly. Not using AI to program is more akin to not having a rocket engine on your car. Would it go faster? Sure. Would it be safer? Definitely not. Do some people enjoy it? Sure. Does anyone not using it miss it? No.
It's also very different because there's a qualitative change between metal woodworking tools and a laser cutter. The latter requires electricity and massive investments.
