Seriously GIMP devs, instead of this overengineered solution, just get rid of layer boundaries. There's a reason no other layer-based image editor has them: they make absolutely no sense and are terrible UX.
I really wish it had Photoshop compatibility mode for hotkeys and behavior. The former is a very common tweak.
Layers having boundaries feels... obvious to me? Like, when I scale a layer, the boundaries are what I'll be scaling. When I crop a layer, I'm cropping the boundaries. If I have a large image and insert a small icon in the middle, should the icon's layer take the full size of the canvas? What exactly is supposed to happen if I insert an image that's larger than the canvas?
A layer in GIMP having boundaries is equivalent, to me, to a shape in Inkscape having a size.
Perhaps the existing code makes it difficult, and I get the impression the devs have been stuck dealing with other tech debt for a long time. But this should really be high on the list of things to address.
And that is the problem. People who have learned tools from what is now an established, multi-editor, digital medium, find they can't do what they wish to do.
I suspect very few even try to make this jump anymore.
GIMP still requires artists to think about and develop their workflow in the sequence that works best for GIMP.
Waving them away like this is a mind trick that the GIMP community should simply ban outright; it's devastating.
(Unless you mean this satirically and it's just gone over my head)
Hypothetically if GIMP just copied the photoshop UI and expected behavior a lot of tutorials for PS translate directly making GIMP accessible, which ultimately plays to the favor of GIMP as it is more accessible in that it's open source, free, and doesn't require subscription or accounting.
Also since GIMP is decentralized and volunteer-ran it'd be interesting to see exactly what Adobe would do about it, if they could even do anything.
Something else that would be nice to see from the open source community would be standardization in the control schema across software. For instance I use Blender a lot, but I also use Inkscape, and jumping between the two is... Less than pleasant because there's a pretty significant amount of overlap, but none of it is able to be homogeneous as there is some hard coding that a keymap alone doesn't allow for convergence.
I don't mean to be rude to the work done to make Gimp, but the harsh truth is that Gimp's UX has been a joke for over a decade
Or have expectations that...make sense? The way GIMP represents layers is unintuitive, at best.
There are some de-facto tools (Adobe Photoshop, etc.) that have paved the way for intuitive UX in this space - no need to re-invent the wheel in areas that are well-established by now.
Mac is blessed with several fantastic image apps. After using Pixelmator Pro for 5 minutes, I bought it. It does all the things I’ve wanted in GIMP, but I can figure out how to use it without hitting Google.
For example, can a mortal draw a circle with GIMP now? Up through the last time I used it, you had to select an ellipse (and hold down ctrl or something to constrain that ellipse to a circle), then stroke it as a path. In other apps, you choose the shape tool, and plop down a circle. While it could be that there was some esoteric case where GIMP’s weird process was nifty, it was markedly worse than everything else in the 99.9% of cases where you just wanted a circle.
For me, it was never that it wasn’t a Photoshop clone. I couldn’t care less about that. It’s that it was almost deliberately obtuse in ways that no alternatives were.
When I crop, resize, move, ... a layer, its boundary is cropped, resized, moved, ... accordingly. What happens if you move a layer without boundaries, like in Photoshop? That's probably intuitive to people who are used to Photoshop, but not to me. What happens to contents that now fall out of the image boundary?
To explain layers in raster image editors to novices, they are often compared to transparent slides. Well, layers with boundaries are simply such slides. If I move a slide, the slide moves, including its boundaries; same with other operations.
Can you still have a layer that is bigger than the image boundary, or would pixels get cropped when they move outside?
What happens if you apply a noise filter? Does it generate an infinitely large layer with noise? Or only generates noise on the visible portions? Or some other arbitrary rect in between?
And how would you handle the case of a small layer with a weird blend mode like multiply/subtract? With no boundaries it now must apply to the entire image below.
I’m sure there are solutions to these individually but it’s clearly a very complex problem to solve all these kinds of cases in an intuitive way.
What am I missing?
I don't care if it's "efficient," we're talking about environments which have orders of magnitude more resources and efficient disk caches and god knows what else. It's nearly 2025.
Tools like Photopea[1] come along and throw a fresh perspective at things all the time, these tools never have the breadth and depth of feature support that GIMP has but basically always manage to "one-up" it over something.
How long will it take before GIMP has usability on-par with Photoshop? How long until it attains the aesthetic coherence necessary to win people over visually? I love GIMP, but is the battle against 20 years of technical debt even winnable?
- bad (in places better called solipsistic) UX
- underlying architectural issues from its dependencies (e.g. OpenCascade's OCCT and Coin3D)
- a flood of competing workbenches and plugins so users struggle with initial workflow, many abandoned or undermaintained
- something of a reliance on knowledge of Python scripting to solve advanced issues
- and (akin to GIMP avoiding non-destructive-editing for two decades) a fundamental architectural issue: topological naming problems that other CAD packages have solved
But things in FreeCAD land are changing really fast -- there's a TNP implementation coming quite soon to core FreeCAD, there's a core assembly workbench, a materials system and really significant GUI and UX improvements.
The reason is things are changing is that that people central to FreeCAD looked across the open source landscape to Blender, and saw how a project can be run, and how commercial companies could consult on top of it.
Everything has changed within a matter of three years. Despite its issues, FreeCAD is now exciting to watch.
Whereas GIMP seems to still be circling around looking for the best solutions to things they never finish. Krita has become the thing GIMP could have been, and it is nine years younger.
GIMP is critically underfunded. Seriously I think it's like one guy making most of the changes[0].
> 7 core developers contributed 10 or more commits in GIMP’s main repository:
> Jehan: 649 commits
> Jacob Boerema: 64 commits
> Nikc: 50 commits
> Daniel Novomeský: 25 commits
> lloyd konneker: 25 commits
> Lukas Oberhuber: 18 commits
> Niels De Graef: 15 commits
People keep asking the world of Gimp as if they have even 1% of Adobe's funding. IIRC no one is working on Gimp full-time, while Krita is able to pay four full-time developers[2].
1. https://www.gimp.org/news/2023/01/29/2022-annual-report/
2. https://docs.krita.org/en/KritaFAQ.html#license-rights-and-t...
Curious to know more. I occasionally look at CAD kernels and wonder about writing a C# wrapper. Is OCCT to be avoided?
Granted, Ton figured out a project of that scale needed funding, but overall, Blender is a huge success as a FOSS tool. Maybe the Gimp and Blender developers so sit down together and have a chat, the tools are often used together after all.
Voluntary fixes are necessarily smaller in scope and suboptimal as a result, leading to more complexity when those systems need to be changed later.
I'm also reminded of Casey Muratori's talk about software architecture being a reflection of the organisation that made it. Open source projects are at the extreme end where contributors and org charts are highly fluid, and communication between contributors is low-bandwidth, accelerating the complexity increase.
Here's the bleak assessment: It's been almost thirty years - If it was going to happen, it would have happened already. The economics and development model just don't support the same sort of usability and in-depth feature development work that can be supported within a large commercial software organization.
You can also observe this in software like language implementations. Ruby, Python, and Java are all rough contemporaries of each other. They were all released in the early to mid 1990's, and they were all released at approximate technical parity. (Basic automatic memory management techniques and simple/slow bytecode interpretation.) Now, flash forward thirty years. While Python and Ruby are still mostly interpreted, Java has been through multiple generations of increasingly sophisticated runtime implementations, now has first rate GC and JIT compilation to machine code.
This is the sort of improvement that can only really be bought by continual long term investment in dedicated engineering. It's what takes to escape local maxima in the design space. If a project can't assemble the resources to do this, it winds up stuck wandering around its current local maxima and maybe making marginal improvements, but never able to break free of the fundamental constraints of its current design.
This will remain true unless there's some sort of investment in additional resources, which brings me to my more optimistic assessment. With GIMP (and other open source software), it's at least possible for outsiders to make the investment. It's possible to make a contribution, and it's possible to improve the situation. This can itself be a useful and profoundly enabling aspect of software, particularly over the longer term.
(I also think this suggests that open source software should tend to be developed in ways that emphasize the discoverability and customizability of the codebase. It's for this reason that I think open source is the key enabling factor for tools like Emacs.)
They were technically reasonably complete but absolutely awful to use - until they started focusing on UX and features desired by industry professionals. In just a few years they went from being cute open-source toys to being serious alternatives for the expensive proprietary market leaders.
I imagine some people would object to things being taken out or significantly altered. An existing & happy (?) user base probably carry weight.
This is not a criticism of the individuals who write code for GIMP.
The FSF, which manages the GNU project, doesn't really have any resources of their own to put into any of the GNU projects. Their role is almost entirely advocacy and some coordination, all actual development is done by volunteers. The GNU project has many many projects that are far more neglected than GIMP, and GIMP is probably on of their more active and well supported 'normal' end user applications.
https://en.wikipedia.org/wiki/GIMP#History
The application subsequently formed part of the GNU software collection
You're correct that it's not "maintained directly by the FSF", that's not how GNU operates, but I feel that GNU and the FSF has a responsibility for the health of the projects which are part of the GNU project.
Does GNU or the FSF ever "put resources" towards a project? Last time I checked, almost all of the FSF's expenditures are towards advocacy. Aside from that they run some horribly outdated infra like that Savannah thing that many projects opt-out of because it's horrible.
That relationship seems to be a little confusing going by this thread, so I think your comment was warranted!
Yesterday I needed to draw an outlined circle… and couldn’t figure out how.
A friend gave me, erm, a backup copy of Deluxe Paint for Amiga way back when. If GIMP were half as approachable as DPaint, I’d still be using it.
Terrible ux for "i just want a circle" - but (forces) open the door to quite powerful path>stroke workflow.
https://graphicdesign.stackexchange.com/questions/696/make-a...
Option A: Build a function that calls all the appropriate actions in sequence, then stick it on a menu.
Option B: Tell users that they're better off doing it manually.
...which inevitably leads to:
Result C: Why don't more people want to use it?, and
Result D: Appealing to programmers who think that's a great idea because it worked OK for themselves, and building more features with the same paradigm, creating a feedback loop.
I didn't think this sort of polish was possible for a free program, but after seeing MuseScore and Blender, it gives me hope that it could happen.
I know how entitled I sound asking for this ;)
YouTube videos of pros using it will blow your mind. It’s really powerful.
I am that kind of decades-long hosted-linux-from-a-Mac-desktop user who checks out desktop linux every six months or so to see if the daily driver situation is ready.
I edit quite a lot of photos and even though Darktable is a mess, I could use it and it's not the only option. I edit vector graphics and I think Inkscape is fine. I like FreeCAD. All of my coding tools appear to run in Electron, etc. etc.
But GIMP isn't an option. It's not even close to being what basic quick correct photo editing needs in terms of a workflow. And I'm simply never going to change what is not really a particularly deep or exotic workflow to fit it.
Krita is _sooooo_ close, and it's not even trying to be a photo editor first and foremost.
This is the purest of comedy. I applaud it. And I think a twenty-seven-year-younger version of me who first used adjustment layers in Photoshop in early 1997 [0] might find it even funnier to imagine this future.
This isn't "skating to where the puck was". This is "skating to where the rink was before they tore it down and built a shopping mall, that they tore down to build offices that they are now going to tear down to build a retirement home for GIMP developers".
[0] when, I note, GIMP already existed. OK so they got a bit distracted building a GUI toolkit, and we should not forget the significant value it added. It's the real transformational product of the entire endeavour.
But seriously: this wasn't voodoo, weird niche case or hypothetical stuff by the early 2000s, when they were still building a GUI image editing app that really relied on advanced users having Lisp knowledge. And they continued to kick it down the road for literal decades.
This is classic open source entitlement. If it's so important to you then why didn't you spend time writing patches in the last 20 years? This isn't a product you buy. Look at the commit history; for almost all of it GIMP is just a few people working on it; between 2 to 5 at any given time IIRC. All of them in their spare time AFAIK. These people are not your bitches to order about.
In full knowledge of the HN guidelines I feel confident in stating that you need to learn when to shut the fuck up. No really – "couldn't you have spent more of your free time on this a bit sooner" is just a shit attitude, and one that you can just keep to yourself.
Adobe don't. The Adobe codebase is cruft that has taken a similarly long time to shake out. Lightroom was seemingly built like a skunkworks project almost like a desktop webapp (scripting around a core renderer, SQLite, simpler mode-oriented GUI) to avoid the intransigence and friction of Photoshop's codebase.
But this is what GIMP is up against. Cruft that earns money, that is driving not just what users want but how they think about what they want.
For GIMP to be more successful it doesn't need live non-global filters like blurs, but it would have been enormously beneficial to the project if it had global adjustment layers, say, 15 years ago.
Then youtube would have been filled with tutorials, there would have been momentum around the project, some commercial support interest, etc.
Kicking the can down the road has consequences. This great Ondsel blog article about how difficult it is to merge major changes into an open source project goes into it in some detail:
https://ondsel.com/blog/freecad-topological-naming/
Some decisions need to be taken at the right time; if you don't, you need a whole separate kind of energy to get them done without stopping everyone else.
(The successful Affinity suite is a result of taking some right decisions back in 2010 or 2011)
> Hey! I also think Adjustment Layers are really important for GIMP. However, Layer Effects will be simpler to start with since they only affect one layer.
To everyone complaining about the UX, let's either accept that GIMP does not have the development resources of Photoshop or else propose specific improvements in the GIMP project backlog.
I mean people keep comparing GIMP with Photoshop and that's obviously incorrect. I'd more or less agree that the "market" of free software image editors is an "open market" and GIMP is a big player there so to say.
Congrats to the team for finally having the finish line in sight !
Ellipse Select Tool 🡢 Draw Circle 🡢 Edit 🡢 Stroke Selection 🡢 Stroke
The 3.0 series represents several thousand hours of work over more than one decade. Soon that is over the finish line :)
(Entitled haters that always show up can take a hike. Time to get the downvotes out.)
My personally biggest issue I run into almost every time I try to use it is the lack of vector layers for text and some mild primitives like lines, squares and circles you can adjust the properties of after you initally drew them.
The other annoyances like for instance the "professional" feature of only saving to xcf can actually very easily be patched if you can compile gimp yourself. They still show a annoing level of pigheadedness from a project otherwse so nice.