> Brush tools now have an additional “Expand Layers” option. When checked, painting past the layer boundaries will cause them to automatically expand so you don’t have to manage the layer size yourself. If you want to expand the layer beyond the current size of the canvas, you’ll need to also check the “Show All” option in the View menu.
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.
You say "just", but I imagine the idea that layers have boundaries is a deeply ingrained assumption throughout the code base at this point. I would love for layers to not have boundaries, but I think prioritizing it below shipping GIMP 3 with GTK 3 support is correct.
That's not how I read it. The fact that layers have boundaries shows up all over the place in GIMP, turning on "auto expand layers" in the brush tools by default wouldn't do that much to "get rid of layer boundaries".
I also second this. I've been using GIMP on and off for occasional image editing for about 8 years now, and I still don't really grasp how do layers work in it.
I really wish it had Photoshop compatibility mode for hotkeys and behavior. The former is a very common tweak.
There is PhotoGIMP[1] that copies the hotkeys and tool layout. It doesn't replicate behaviour exactly obviously but it does make it actually usable for me as someone who used Photoshop a lot in the past, and was eternally confused by GIMP.
I've read the whole thread of comments and I'm really confused. For context I'm a long time GIMP user and used Photoshop a few times at a very basic level.
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.
For example, does it not seem intuitive to you that it should be possible to take a brush tool and paint on the canvas? In GIMP, you can usually do that, but sometimes you can't, for reasons that are initially baffling. Once you figure out it's to do with layer boundaries it becomes merely annoying and frustrating. Once you get used to doing "Layer to image size" things get a bit easier, but needing to a) know that and b) constantly do that is not a useful feature.
Not a fan of "this" comments but, very much this. The way layer boundaries work in Gimp is tremendously confusing and annoying.
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)
Homogenizing expected behavior is a pretty good idea, it allows open source software to compete at a commodity level instead of a principle or fundamentals level - which considering the open source position would make a pretty good deal of sense as quite a lot of it is free, e.g. GIMP, Inkscape...
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.
As a concrete example, when Blender finally made left click the default selection button (in harmony with virtually every other 3D software out there) it made the learning burden much, much easier for new users to shoulder. This, combined with many other UX improvements have made Blender possibly the most popular 3D software out there today, instead of the weird choice.
> Homogenizing expected behavior is a pretty good idea, it allows open source software to compete at a commodity level instead of a principle or fundamentals level
That applies if your only goal is to create FOSS software that competes head-on with proprietary applications, so that being FOSS is the only differentiator.
But obviously, this isn't always applicable as a general principle. If you want to enable new functionality and support new use cases, where there are a variety of approaches or trade-offs, and conventions aren't well-established yet, you probably shouldn't presumptively conform to an a priori monoculture.
> 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.
This is a great counter-example, where adhering to well-established conventions for problems that are already solved is advisable. There's been a lot of divergence in UI design recently, with lots of applications moving away from decades-old standards for purely aesthetic reasons, and creating huge usability regressions in the process.
> expectations that come from using other image editors
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.
Even editor like photoimpact which appears about 20 years ago works almost the same way about the draw layer. You just draw anywhere on the whole canvas, that's it.
And if you want something that has specific size and resizable and can be placed out of canvas. Use object instead.
Why would gimp even resist to make draw layer that have specific size at first place?
I’ve used Photoshop for like an hour total in my life. I have no ingrained love for it whatsoever. I’ve used GIMP quite a lot over the years, and I’m used to it.
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.
I can confirm, the first focus of Gimp must be the UX (which could be just cloned at this point), and the rest is not so bad to my liking. Right now Gimp is just unusable for anything serious.
I honestly don't see the problem with layers that have boundaries that are independent from the image boundaries. Maybe it's because I learned my way around Gimp before I used any other image editor, but it makes perfect sense to me.
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.
Yeah, except it’s not slides. It’s a virtual canvas and there is no reason in the whole world for it to behave like it’s something physical, when it’s not. It makes zero sense, there shouldn’t be any checkbox in the first place. Just make it how it should be and never ask me. There’s enough checkboxes already. How can you develop a tool for designers if you never ask them first?
Layers in GIMP can be smaller than the image they are part of. So if you try to edit a layer outside of it's boundaries you don't get anything. Pretty much all editors do this as an optimisation (no point storing an entire layer if it's almost entirely empty transparent pixels), but GIMP is unusual in exposing this to the user and expecting them to increase the layer size manually. In other editors the layer is conceptually the full size of the image and these boundaries are managed automatically. (In fact, usually the layers are unbounded in size and can expand to be larger than the canvas. Very useful if e.g. you are importing a background image and want to be able to shift it around a bit)
Not just smaller, but you can even have them be larger than the image. Then you can move the layer around and have the image essentially acting as a cropping window into that layer. I most commonly experience that when I've imported/pasted in a larger image as a layer
Nice solution would be having this boundary stretching automatically as proposed in this thread but also exposing 'bounded layers' as separate tool like frames in Indesign.
There’s several things which break down if you eliminate layer boundaries.
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.
This depends on the image editor you use. I'm pretty sure that PS saves whatever is on the layer, even if it's extends past the boundaries of the image itself. At any time you can open the file, and move the layer and get access to whatever was masked off.
If you "flatten" the layer, then you might lose what's beyond the boundaries.
> Not if you're saving to the GIMP project file format.
Ok, but if I understood correctly we're asking GIMP to remove code paths that have different layer boundaries, so that would surely affect GIMPs project file format?
wait GIMP does vectors now? I hope you don't mean that stupid useless plugin that renders to a bitmap layer and you can't adjst again afterwards? Or has that improved while I wasn't looking?
going to try again when I get home - would be so nice to just click and adjust text when its not quite the right size or position. I hope I can draw vector line as well.
that was actually something that drove me almost batty once before I installed an old PSP9 in wine and used that instead. I needed to adjust thesize and position of several lines in relation to each other and i was unable to do that even with that stupid plugin.Using 1 layer per line would have worked but I though that was a bridge too far at the time.
text has definitely gotten better. i remember when text could not be modified (as text) after initial creation -- but this has been fixed quite some time ago.
also, paths and text can be exported to svg format, but i still wouldn't call gimp a suitable editor for rich vector graphics. the vector features are more just a means to a (rasterized) end.
I was recently trying to make text along a path in Gimp and holy hell is it weird.. you create a text object, then create a path and with the path selected, right click the text object layer and choose “text along path”, and then you have to “stroke path”, IIRC.
But what that does is renders some kind of object (don’t recall if it’s rasterized or what). If you later notice a typo, or want to change the font, font size, or path a little bit, you have to throw away the rendered object, make your changes to the text object (hope you kept it as a hidden layer or something!), and then re-render and re-stroke it.
I’m glad I was working on something for fun (bottle label) and that I didn’t particularly care about the end result.
I genuinely don't understand why the solution this layer-boundary BS is not to just default the layer boundary to the image boundary, or the contents of the layer, whichever is larger, always, done and done.
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.
Another comment mentioned GIMP may have assumptions of bad UX within their codebase which makes me think about long-lived and large scale projects like this in general. The technical debt of GIMP has been slowly amassing (like all projects) since 1995 (wow!) and I assume that as every year goes by it gets increasingly difficult to do a large scale re-write of any part of the logic.
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?
Another really long-lived package, FreeCAD (it's about six years younger), has tremendous parallels:
- 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.
> 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].
In truth, GIMP maintainers deeply enjoy the control that "no strings attached"/"no obligation" development brings them. They've alienated most potential sponsors because they're happy with their lack of results. The missing funding angle only matters as an excuse for their own disorganization.
I haven't double checked but I think at least one of your listed names is banned from twitter.
I mean, anyone can report anyone for whatever and you will never reach tech support, because tech support at big social platforms never ever responds. Facebook, Twitter, YouTube are all the same. You have to have some serious connections to get a ban lifted.
Actually, I'm a former team member and my personal account is banned on Twitter (which I discovered when I tried to log in after half a year of absence). He could be thinking of me, in fact! :)
Not really, no. They have sufficient funds to hire several developers for several years full-time. They are just dragging their feet to organize themselves into a non-profit and start using those funds. The latest news is that they will probably finally announce a non-profit later this year. Hopefully.
I tried to use FreeCAD a few years ago to do some simple object modeling for 3D-printed prototypes. The GUI was so complex and idiosyncratic that I found it more efficient to just learn OpenSCAD's modeling language instead (which served me really well).
Yes, absolutely. It was where GIMP still is now, for artists.
It's definitely been idiosyncratic (if not solipsistic), and still has IMO some maddening features. And it still [0] has a core flaw that is being mitigated.
OpenSCAD is actually very limited in ways that don't become obvious until you get into a bRep CAD system at least. But it's how I also got into CAD. I wanted to know there was at least something I'd be able to use for my own ideas, and the fact that OpenSCAD exists is definitely a blessing.
If you like it, you might find Build123D [1] interesting: this is a Python (and very pythonic) environment built around the same kernel as FreeCAD.
But I got from OpenSCAD to FreeCAD and I am very glad of it; it's an amazingly capable bit of software once you get past the pain (in the same way Blender is, I gather).
FreeCAD 0.21 has many nice new things in it. 0.22-dev has more, and 1.0, due at some point in this year now, is going to be a pretty major leap forward.
And at least now we have the amazing Mango Jelly Solutions videos on youtube. I recommend them; you'll learn the right way into FreeCAD.
GIMP is not an amazingly capable bit of software for typical designers. It's broken and hobbled.
[0] the topological naming problem: being corrected in the core distribution at the moment as they head to 1.0
Thanks for the pointer to Build123D -- I really like the idea of building 3D models as code, so this might be a great alternative.
My use case back then was working on prototypes for plastic products we'd eventually be injection molding. I found OpenSCAD to be an extremely effective tool for quickly iterating on designs. I'd tweak some parameters or code, 3D print a batch of samples, hand them out to testers for feedback, rinse and repeat.
Then, once the design was production ready, we'd hand off the final protos to the engineers who would design the injection molds. I'm sure they were using Solidworks or the like. OpenSCAD added a lot of value in the early design phase of these projects, but wasn't involved past prototyping, so I suppose we never encountered its limits.
FWIW I just picked up FreeCAD a few weeks ago with zero prior CAD experience and I was able to create a few simple widgets for my 3d printer (a shower soap dish and a bottle for my daughter's toy doll) without too much fuss (took a few hours of learning and few hours of actual CAD work). I did have to ask a few questions on the FreeCAD forum (and got a bunch of friendly, helpful responses), but that's to be expected learning complex software like a CAD program.
In short, the latest version of FreeCAD (I'm using 0.21.x) is absolutely approachable for beginners and apparently works well for advanced users. I'm quite impressed with the project!
I am almost as far as you can get from an expert (and I am sure there is one here who can explain it better and hopefully correct me) but:
For example the TNP issue derives from OCCT (or something in the stack close to it, I am not exactly sure) not really handling face naming at all.
So if you want to avoid topological naming issues (which is a hard problem in CAD), you apparently have to do some work to track before and after and reconstruct your face naming from either side of the OCCT black box.
Then there are various fairly entrenched issues to do with filleting and chamfering. Basically, both these operations will fail if a chamfer or fillet would completely consume an existing edge. It also sometimes creates impossible objects when filleting, or used to.
Booleans can be slow.
And more generally, it seems if you track the FreeCAD project that OCCT can be inscrutable when things fail; error messages aren't the greatest etc.
The flip side of OpenCascade is that it seems to be highly portable and has for example been compiled to JS with Emscripten for this astonishing thing:
It's a monumental open source project, for sure, and it's definitely not nothing that we have an open source CAD kernel; these are projects that perhaps have to extend beyond the working life of an individual developer if they are to be stable. And there are loads of projects built around it. So it's absolutely consequential and we're lucky to have it.
If you want an open-source kernel, you don't have much choice.
Truck and Fornjot are incomplete and not quite ready for prime-time. libfive is FREP, not BREP.
OCCT is the useable of all. But it also has old architecture, all sorts of imperfections (some of them described by the other guy here), and the code quality isn't great, I'm told (by much more experienced people).
Other CAD programs haven't solved toponaming issues, they mitigated them. You can still break a model in SW and other commonly used 3D CAD programs, it's just more difficult to do.
The example to point to is Blender, for inspiration on how to manage this successfully. Ton has done a heck of a job making Blender into a real alternative, even with the codebase existing and being worked on since 1995. The UX and UI overhaul in 2018 (Blender 2.8) was a big undertaking, that had a big impact on the success of Blender, maybe something similar would be possible for Gimp too.
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.
The problems with GIMP are the same as Musescore before it was bought out - Having dedicated designers/programmers allows more sweeping and coherent changes to be made.
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.
> How long will it take before GIMP has usability on-par with Photoshop?
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.)
Python is the most popular language in the world and used by all machine learning and AI applications. If that's what failure looks like I don't know what success looks like.
I wasn't talking as much about marketplace success as I was about the ability to support engineering efforts to develop specific features requiring high amounts of sustained, focused effort.
There's a big difference between 'high engineering spend' and 'widespread adoption'.
Blender and KiCad are both great examples of what's possible.
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 have a suspicion theory that Photopea is not some magical one-man project that is so good in the browser, but just a Remote Desktop from browser. It looks very Photoshop CS2-ish to me, and in the very beginning it looked identical, iirc. I don’t believe it’s some genius (graphic-terms) project, but just a genius remote-desktop implementation. Hence it works well in the browser. What do you think guys? Maybe someone who uses the project all the years noticed it’s very different and evolved over time, and is not just a PS reskin?
I am very grateful for GIMP, but I hope that the UX can be improved. It gets the job done, but it always feels a bit janky to me. Wish it felt more professional like Photoshop.
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’ve been using Krita for a year or so now. At first I found the UI very confusing, but after learning the top bar is just as important as the side bar it really works.
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.
I'd like to congratulate the GIMP team on the upcoming major release. Lots of volunteer work goes into open source projects, and it's remarkable for a codebase to keep evolving over the course of nearly 30 years.
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.
Isn't the very concept of "open market" meaningless in the context of free (libre) software?
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.
I don’t understand the negativity in may comments, professionals use photoshop or some other tool anyway (if they can afford it), Gimp was always a free, mostly useful alternative for amateurs like me and I am grateful to the contributors.
Hah! That was my exact example of its UI weirdness. It’s not that it’s different from Photoshop, but that it’s different from every other tool I’ve ever used to put a circle on the screen.
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.
I say this as a programmer: that's such a programmer excuse for an awful UI. I'm not directing that at you, but at the group who decided how to draw circles on the screen.
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.
At that point just have a Shapes tool with every shape under the sun. Just having a dedicated tool to draw circles seems like a waste of valuable UI surface.
Well, right. I meant that to be more illustrative than literal.
That’s what other tools do, and what I think GIMP should do: provide a shortcut for the basics (circle, oval, square, rectangle, triangle, etc.). If you want to draw a tree, that’s on you. Put a box around a thing? It should help you.
After thinking about it I don't disagree, and can only offer a data point that I don't think I've ever personally needed such a tool, even as a Gimp noob.
GIMP is infuriatingly good. Its mostly great but has some weirdness that ruins everything in the end. Its issues are like the Spam in that Monty Python sketch.
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.
And I'm criticizing their priorities, which I can do -- especially if you choose to be in the realm of GNU and open source.
I understand their "rights," it is absolutely their choice. But...
It has been this way for a long time, but what they don't understand is they could very likely be doing greater good to stick it to, e.g. Adobe with just a little bit of humbling, which would buy a whole lot more popularity and acceptance.
Of course you can offer (constructive) criticism. But raising the same thing every time GIMP comes up goes well beyond that and is just disruptive. You need to accept that your criticism has been heard, and that it has been rejected.
And I actually agree a different name would be in the project's best interests. But I also accept that reasonable people can disagree, and that I'm not the one maintaining GIMP.
That's an incredibly ridiculous sentiment; you're only allowed to express an opinion once? I absolutely fail to see the value in such a norm; sometimes good ideas need repetition.
Free speech, et al, means I'm absolutely allowed to be annoying if I think it's worth it.
I did not say "you're only allowed to express an opinion once".
But please, show me a project you worked on, and I will show up to forcibly demand a change you don't want every single time the project comes up. And I will guarantee you that very quickly you will find it exceedingly tiring.
I think my problem with your analysis here is that it's like "a personal project."
It's not. It's GNU software. And to me -- choosing to use a license like that is something like taking up a mantle of freedom. You're part of something bigger, and I can't imagine that wouldn't include discussing out loud what direction the software should take.
I think you are in a very small minority. I've never encountered anyone balking at the name, even in educational settings.
Your interpretation -- which you didn't even specify! Many folks won't even know what you're talking about! -- is not the default in my experience. I usually think along the lines of "lame".
In other words, your perspective is the one that seems childish to me.
GIMP is known to be a term for something or someone that has less abilities. Whether you go with "it makes it sound like bad software," or the more recent and reasonable "it's an ableist slur;" outside of this circle, yes there is much balking.
And while I also do bristle a little bit at the general thing of "lets change the name because someones offended," I also understand that it's always a weighing test.
And here, given Adobe's traditionally damn near absolute chokehold on this space, I absolutely believe that, had they changed it a long time ago -- we could all be in a better place here.
> One area we’re “ahead of schedule” on is the much-requested non-destructive editing!
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.
So they're finally doing it and they're still getting grief.
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.
Part of the problem GIMP has is that they chase perfect ideas at the expense of good ones.
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:
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)
Also here it is -- a moment of can-kicking in action, from that thread:
> 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.
As the person who said that, I don't 100% disagree - but also, I was just starting to look into non-destructive editing and had no idea of the scope. Since I didn't want to impact the much bigger kicked-can of GIMP 3.0, I thought having some form of NDE would be better than none at all - your "good solution" rather than "perfect solution".
(Also, it's not just non-destructive blur. All the color tools like Color Balance, Hue-Saturation, Levels, Brightness-Contrast, etc are internally GEGL filters and thus are now non-destructive. It's still early but we've already gotten positive feedback from users on how it's improved their workflow, or at least made it "less bad")
The good news is that now that we've worked on NDE, I have much better idea of how adjustment layers could be implemented and hope to implement those (or at least an intermediate step of adjustment layer groups) for 3.0.2. From other people's comments, it seems like that's the next really useful feature to have. :)
GIMP is one of those things which make me wonder what GNU actually is. It's the GNU Image Manipulation Program, but it's very obviously dramatically and chronically understaffed. What about the GNU project is preventing them from putting more resources into their image editor?
This is not a criticism of the individuals who write code for GIMP.
What about the GNU project is preventing them from putting more resources into their image editor?
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.
But why? Why has the FSF neglected GNU, why has the FSF neglected themselves by not ensuring they have the funding necessary to manage a project of the scale and importance of GNU?
Because the FSF is a software freedom advocacy group, they do not do software development. The FSF also doesn't "manage" the GNU project, which is a entirely volunteer project that is managed by it self (https://www.gnu.org/gnu/gnu-structure.en.html); they do provide critical infrastructure for both GNU and other projects but that is then manage by volunteers.
GNU hackers do what they want, when they want it, sometimes they get sponsored or backed by a company, but that is a rare thing ... question should be why aren't software development companies sponsoring developers to work on GIMP, GNU, and other free software projects?
Mostly ideological I would guess. The sorts of people the were/are running the FSF didn't want to involve themselves with the sort of 'dirty' compromises needed to raise significant funds and end up beholden to large, almost certainly corporate, donors.
This is one of the main reasons why Free Software lost the 'war' to Open Source back in the day.
Because GNU are on a Mission. They’re not out to make things people want, they’re out to make things people ought to be wanting (according to them). This is not necessarily bad - the world needs some idealists - but it does interfere with fundraising.
this seems like a purposely malicious take on it. GNU people, and the people who develop the gimp, are on a mission to make things they WANT TO MAKE. How do you get the nerve to prescribe them as some form of missionaries that goes around telling people "you should want to modify your layers THIS way, simpleton" ?
And as far as free software, I think they generally think "people ought to care more about freedom for everyone, than closing stuff up"
It is a purposely malicious take! The question was why the GNU project has put itself in a place where it cannot assign resources to the GIMP project, to make GIMP more like what the average person wants it to be.
The GIMP developers say “we want our layers to work like this, take it or leave it”, and they have every right to do so. They write the code, they pay their own bills, they get to call the shots.
The GNU people say “software should be free-as-in-speech”. That is certainly their right, and to some extent I agree with them. However, that ideological stance means that the GNU project does not have any resources it can assign to the GIMP project (or anyone, for that matter).
The application subsequently formed part of the GNU software collection
And it's part of the list of "GNU Software" on this page: https://www.gnu.org/software/software.html (And no, that's not a list of all GPL-licensed software, it's a list of GNU software).
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.
I don't really know the current status or feelings of the GIMP developers, but I know GTK and GNOME have formally disassociated themselves from GNU, but it took them many years to get de-listed on that GNU packages page as Stallman flat-out refused to do so, as he believed that projects are unable to disassociate from GNU.
The GnuTLS people have had similar problems. It's still listed on that project page.
My point is: that page only reflects what Richard Stallman considers to be part of GNU, not what the developers of that project feel.
Yes, and like I said, it took the GTK/GNOME people years of complaining to get them removed, and the GnuTLS people still aren't removed after more than 10 years of complaining. LWN and other people documented the background on all of this to some extent, and if you're interested I think I have a text file with some link/details somewhere (which I can't seen to find momentarily).
So that list is worth bugger all for the purpose of this discussion.
No, it's worth quite a lot in this discussion, actually. It tells us that the GNU project considers GIMP part of the GNU project, regardless of what the GIMP project thinks. That means that the question "why does the GNU project not provide adequate resources to GIMP" is perfectly appropriate.
No matter what Stallman thinks, this kind of relationship is a two-way street. GNU or the FSF can't just unilaterally declare it to be "part of GNU" and then unilaterally "provide resources". Not only are they unlikely to do so if the relationship is adversarial, this sort of thing needs cooperation from the other side as well.
Either way, this is getting a little tiresome. I have explained there are disputes and complexities about what is or isn't a "GNU project" and I don't quite understand how anyone can deny that these disputes and complexities exist (regardless of how one might feel about them).
> What about the GNU project is preventing them from putting more resources into their image editor?
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.
To be fair to you, I think it's a valuable comment and the replies were insightful to me. Maybe your comment was being read as anti-Gimp (Gimp stories always get a lot of low-effort "Why hasn't Gimp done <x> yet??" comments). I love Gimp and I upvoted your comment because I've wondered similar things too -- just what is the relationship between GNU and GIMP?
That relationship seems to be a little confusing going by this thread, so I think your comment was warranted!
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.