Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GIMP 3.2 released

gimp.org

Post reply on HN
Print view View original

81–90 of 92 posts

Re: GIMP 3.2 released

#81

Post by selfhoster1312 »

Alupis wrote: post #78
selfhoster1312 wrote: post #65

Earlier quoted context omitted.

This is insulting to our craft, like going to a woodworkers convention and assuming "most of [them]" are using 3D-printers and laser cutters. 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…

> Half the developers I know still don't use LSP 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…

I don't use an IDE under the common definition. All my developer friends use neovim, emacs, helix or Notepad++. I'm not a student. The people i have in mind are not students.

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.

Re: GIMP 3.2 released

#82

Post by 1718627440 »

Alupis wrote: post #78
selfhoster1312 wrote: post #65

Earlier quoted context omitted.

This is insulting to our craft, like going to a woodworkers convention and assuming "most of [them]" are using 3D-printers and laser cutters. 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…

> Half the developers I know still don't use LSP 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…

When your language has neither name-mangling nor namespaces, a simple grep gets you a long way, without language specific support. Ma editor (not sure if it counts as IDE?) uses only words in open documents for completions and that is generally enough. If I feel like I want to use a lot of methods from a particular module I can just open that module.

Re: GIMP 3.2 released

#83

Post by 1718627440 »

cmyk_student wrote: post #76
hagbard_c wrote: post #75

Earlier quoted context omitted.

Many years ago I tested a native OS/2 image editor with this feature. It also made it possible to undo an individual transform or effect in the current stack while leaving the rest untouched. Will that be possible in Gimp as well?

Yes, it's planned for transform tools and already possible with filters. Technically our transform tools are already capable of this (they use GEGL operations the same as our non-destructive filters). We just need to tweak it to not immediately commit the transform, and then implement a UI.

When does the final calculation happen then, at file save/export? Will be unexpected. Or does it end up in the final format? That's going to be a nightmare, because then you can't use GIMP to redact data anymore.

Re: GIMP 3.2 released

#84

Post by 1718627440 »

Timon3 wrote: post #69
enriquto wrote: post #44

Earlier quoted context omitted.

> I always found it odd that scaling down an image now and then scaling it back to its original size 2 seconds later with the same tool resulted in a loss of quality 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 frequenc…

From a developer perspective you're obviously correct, but from a user perspective it doesn't make sense that the tool discards information, especially when competing tools don't do that. 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!

Cropping IS a destructive operation. If the program isn't throwing information away, then it doesn't actually do cropping, but some different operation instead.

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.

Re: GIMP 3.2 released

#85

Post by 1718627440 »

cmyk_student wrote: post #52
kernc wrote: post #39

Earlier quoted context omitted.

Did you also manage to enable menu icons?

That was a feature in GTK2 (the GUI library we use) that was removed in GTK3. We could try to fight the library and reimplement it ourselves, but it'd take a developer dedicated to do it. I miss the menu icons too. :(

It got deprecated only in 3.10 and you can compile against that and link it with the latest Gtk+ 3 library. I do this for my programs, because I don't like it when the widget toolkit ignores my OS settings.

Re: GIMP 3.2 released

#86

Post by Timon3 »

1718627440 wrote: post #84
Timon3 wrote: post #69

Earlier quoted context omitted.

From a developer perspective you're obviously correct, but from a user perspective it doesn't make sense that the tool discards information, especially when competing tools don't do that. 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!

Cropping IS a destructive operation. If the program isn't throwing information away, then it doesn't actually do cropping, but some different operation instead. 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.

I genuinely can't empathize with this objection. To me it's basically the same as arguing against Undo/Redo in a text editor because someone could come along and press Undo on my keyboard after I've deleted sensitive data.

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%?

Re: GIMP 3.2 released

#87

Post by dingdingdang »

masfuerte wrote: post #13
hnlmorg wrote: post #7

I use Gimp pretty sporadically but the latest UI refresh (I’m guessing introduced in 3.0?) completely baffles me. 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.

Select a rectangle. Stroke or fill the selection. I agree it's a bit counter-intuitive, but afaik it's always worked like that.

It always had worked like that and it has always been a 100% nonintuitive and peculiar way to deal with this operation

Re: GIMP 3.2 released

#88

Post by enriquto »

Timon3 wrote: post #86
1718627440 wrote: post #84

Earlier quoted context omitted.

Cropping IS a destructive operation. If the program isn't throwing information away, then it doesn't actually do cropping, but some different operation instead. 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.

I genuinely can't empathize with this objection. To me it's basically the same as arguing against Undo/Redo in a text editor because someone could come along and press Undo on my keyboard after I've deleted sensitive data. 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 cro…

but nobody argues against undo/redo in gimp!

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!

Re: GIMP 3.2 released

#89

Post by Timon3 »

enriquto wrote: post #88
Timon3 wrote: post #86

Earlier quoted context omitted.

I genuinely can't empathize with this objection. To me it's basically the same as arguing against Undo/Redo in a text editor because someone could come along and press Undo on my keyboard after I've deleted sensitive data. 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 cro…

but nobody argues against undo/redo in gimp! 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!

Sorry, but I still don't see it - the text editor analogy is stretched far too thin. If I share a project file, I want the other user to see all this stuff. If I don't want them to see all this stuff, I send them an export.

It would be a true shame if every useful feature was left out due to 1% of use cases becoming slightly different.

Re: GIMP 3.2 released

#90

Post by Alupis »

unmole wrote: post #80
Alupis wrote: post #78

Earlier quoted context omitted.

> Half the developers I know still don't use LSP 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…

I guess I'm nobody then. 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.

Ctags are very limited and unpopular. Most people do not use them, by any measurement standard.

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...

Post reply on HN