> GTK 4 has been available for a few years now, and is on the project's radar, but the plan was always to finish the GTK 3 work first.
Also, since you're here: is it just a matter of glucose, and thus if someone were to port it to GTK4 that patch would be accepted, or it's quite literally "no user cares about library versions"?
At the moment, new development is encouraged to follow the GTK3 -> GTK4 migration guidelines (e.g. use gtk_widget_set_visible () rather than gtk_widget_show (), don't use gtk_widget_destroy () since it's been removed, etc). I don't know a specific issue tracking GTK4 at the moment, but I can check.
Probably more than 10 years ago.
And note that the software used wxWidgets, so most of the changes were encapsulated there. Only a very small part of GDK/GTK was used directly, with wnck already used as a helper layer (but the functionality in question broke there as well).
So even if GTK came from GIMP, if the later development in GTK was not made specifically for and by the GIMP project, the migration must have been a nightmare. Especially in a project that had so many other things to worry about, non-destructive editing alone.
And to repeat such a migration now again for GTK4 will not be very enticing.
If you aren't Gnome, GTK is not for you.
And here we are, having written articles about Gtkmm to The C/C++ Users Journal, I no longer care and run systems from Microsoft/Apple/Google instead.
Not sure Gimp devs would be willing to switch to C++ for Qt though.
Which is ? GTK 6 ? GTK is a moving target (like a lot of libraries those days). /s
Not to say that it's irrelevant just that at this point it feels like it kind of missed the boat in this space.
Still quite relevant, especially in some areas. Think about packaging and labeling, there's just not really a way around print in these areas.
Besides that, digital print is the future. Print also needs to become clever and data-driven, more personalized and tailored to the recipient, but that's hard work.
Example: Just last week I received a catalogue with the fall/winter collection of a larger clothing brand. I threw it away immediately. Lots of things in it that are not my size, or my style or whatnot. A personalized product would have helped. Pick articles similar to those I own (you got this data from my previous orders), only show articles that are available in XXL or larger (look at the sizes I kept and did not return) and that's it. "Hey Martin, these are _your_ pieces for the winter season, enjoy!" Maybe it's only 16 pages then instead of 50+ but it would have been a much better experience for me. Also cheaper to print and ship for the store but with a much higher value. But yeah, programmatic printing is hard(er) to do then order 100k catalogues from the cheapest shop you'll find.
If Inkscape could get a UI for precision positioning, something you could e.g. design an entry form in; and Scribus could polish up, I think a lot of people would move to a FOSS workflow.
Edit: To the FOSS hackers who are down voting. You can buy state of the art professional image editing and design software for less than a hundred dollars. Deliver work to one client and you've paid for all your tools. Why would a professional waste their time with GIMP, when they can use all those hours working for clients with good tools and get paid?
We're speaking about professionals now. If they need to, they will use devices without any personal data for their work.
And it's not like your average graphical designer can go through the trillions of lines of code in an open source environment to determine how secure it is. They're busy doing their job.
The free market is a much more effective process for getting quality tools for the rest of us. There's nothing short sighted about it. As a professional I pay a fair price for my tools and the developers get a salary so they can continue to improve it. In the sector of image editing and graphic design, Affinity is a perfect example: cheap and top quality.
Open source software will not improve for any end user by more people using it. Only programmers can improve it, and only if they want to. Usually they don't want to, because the users are not paying them.
Mobile has been won, “Windows Server is dead” (read on this site many times), many desktop tools are floss now, even M$ is writing them. Your small industry not withstanding.
And I'm getting much more in return as a customer, where I can actually report a bug and get it fixed or ask for a feature and get it implemented, instead of being told to f myself or fork the code, by some angry free developer.
If normal non-developers don't have software tools that they can use to be creative, then you're just throwing all these people into the bin of being only consumers. Who benefits from that?
Even last Dan Margulis' books are about Lab and not CMYK, like older ones.
And looks like no native Lab (or CMYK, for that matter) in 3.0: data is still sRGB, and converted before and after tools.
It is bad.
Lab has much more wide gamut that sRGB.
We also load palettes (ASE, ACO, etc) in CMYK, CIE Lab, etc. It's true we don't have a dedicated CMYK/LAB mode yet, but 3.0's color management work laid the foundation to implement this much easier in a future release.
To be fair, though, all industry professionals are forced to be Photoshop addicts. But Photoshop's UI is objectively awful; it's the 10,000 hours you spent in it that makes it seem sane. You could have learned Thai in 10,000 hours, too.
The real weaknesses in GIMP have been in its lack of some necessary functionality, especially some that is necessary for print. The great thing about being GPL is that when the stuff is eventually added, you own it forever.
I'd probably try and power through if there was even close to feature parity, but it's only just now catching up with where Photoshop was in 1994.
GIMP was meant to be a drop in replacement for early photoshop, so it makes sense that it follows that UX idea.
It's just Photoshop addicts needing the UI to be identical to
Photoshop because when they use GIMP their muscle memory is
broken.
Not to say that there isn't more work to be done, but I think there's a lot of good work done by volunteers already.
Also who thought putting stuff like "Cancel" and "OK" into the title bar was a good idea?!
That's one of the things I dislike more in GTK3. It seems dictated by the false belief that everyone is running software on a tablet screen in which windows don't need to be dragged around and open always at full screen, so the more space is used for widgets and input/output the better.
Windows and Google fanboys ?
A titlebar is a titlebar. If you are not able to draw your "OK/Cancel" dialog box somewhere else, just don't do it.
As a longtime casual blender user(since the late 90's version 1.7 on irix) that was less a "complete ui change" than it was a "we released a press release saying we did a complete ui change" the biggest actual difference was to swap the mouse buttons.
See, blenders ui was always good, it was designed as a professional tool, that is, designed to be used for many hours a day. it had a very quick and smooth operating interface flow. However it did have a reputation, deserved, as having a bit of a learning cliff. when your primary design paradigm can be best described as having a 101 button mouse. there is a bit of learning involved. but two things changed, one, blenders ui flow started being copied in other 3d programs and became more mainstream and acceptable. and two, the blender team kept working backwards, adding slower, but more discoverable paths to the tools.
Now I am not a member of the dev team, actually not involved in the community in any way so I am probably wrong, but the way I see it, there was a sort of very sticky reputation blender had that it was "too hard", this was mentally blocking a lot of potential users, so the only solution was to loudly say "hey we redid the whole ui to make it a lot easier", coughs, adds dark mode. it is still just as "hard" as it always was, but because people think it is easier they will take the time to learn it.
I'm in my thirties now. Slow and steady wins the race.
Congrats to the GIMP team, can't imagine the catharsis they will experience when 3.0 officially drops.
Many other projects would have simply switched to a different versionning scheme and got rid of beta versions to simply iterate on releases like web browsers do nowadays.
Thanks for the catharsis word, I have to look it up for the meaning.
20 years or equivalent to 5 times Olympics games, is a very long time to develop and improve a software. It's now comparable to the real-time Linux kernel, another open-source software albeit it's a kernel not a user application [1].
Any other open-source software that has a comparable development time that I'm not aware of? But as the old adage says it is better to be a tortoise than a hare, as long you're winning the game.
[1] 20 years later, real-time Linux makes it to the kernel:
https://news.ycombinator.com/item?id=41584907
[2] The Tortoise and the Hare:
I remember Blender back then. The days of watching squares slowly render over 2-7 minutes each for some cool project I made with lighting.
Has much new been added to editing/functionality or just speed optimisations?
I mean, even if you aren't using it now, it's probably worth looking at e.g. the latest release notes https://www.blender.org/download/releases/4-3/ just to see the array of things improving and adding onto stuff that mostly didn't exist 12 years ago.
GNOME famously had that file picker thumbnail issue open for 18 years.
Emacs. Free and open source. User software. 40 (50) years in development. Mythical
Its great to see it improving, and adding big things like CMYK
Eventually I learned all the more advanced functions in Photoshop, specially the non destructive editing stuff, and couldn't really go back to Gimp. The muscle memory of using it eventually atrophied and nowadays I have a hard time using Gimp.
All that said, I don't do much 2D/3D work nowadays, so I've been using Krita for almost a decade and it feels like a decent PS alternative, with a more similar interface...
Not in software. I can't think of a single example of that. Slow doesn't win the race, it means that the dependencies will go out of date, and some of the work has to be repeated over and over to match the changing landscape.
I do like GIMP though, it's my default image editor.
https://alvinalexander.com/gimp/gimp-how-to-create-draw-circ...
Please gimp devs, fix the basics
the actual shortcut is ctrl + shift + L, btw
A tip for others that feel the same: if you've used Photoshop before and are used to its UI, try the free Photopea website. It's a Photoshop "clone" that works really well in web (I believe it's a solo dev doing it too). It's replaced Gimp for me lately.
I also use Photopea from time to time. Can recommend.
Websites are not automatically free or opensource, they also require internet access and can sneakily copy the files you are working with.
If photopea is free today, it may cost money tomorrow.
Krita exists for Windows and macOS too nowadays.
You have made one of the most baffling logical errors that commonly crop up when people criticize browser-based apps.
Browser-based apps execute in a sandbox. They are more constrained in what they can do in comparison to a traditional program running on your machine. Any nefarious thing a browser-based app can do, a local program can do, too, and not just that, but they can do it in a way that's much harder to detect and/or counteract.
There are good reasons available if you want to criticize browser-based apps. This is not one of them.
likewise monitoring and detecting network access per application is easy. tracking down which browser tab is making which network connection is a lot harder.
> Any nefarious thing a browser-based app can do, a local program can do, too, [or worse!]
for a desktop application, at least on linux there are tools available to further constrain its access to the system by monitoring its activity, removing capabilities or placing the app in a container or even a VM. (VM are available on windows and mac too, but i don't know about other features)
to contain a browser app in this way i would have to run a contained copy of the browser as a whole, and i still can't easily limit network access.
further, almost all desktop applications on linux come from a trusted source or a trusted intermediary and have undergone at least some kind of review, whereas browser applications can be reviewed but it is non-trivial to ascertain that i am running the exact same version that was reviewed.
it is possible, and it is my hope for all this to change. i actually believe browser applications are a good idea, but the ability to audit, and constrain browser applications needs to improve a lot for that to happen.
Certainly a website is allowed to process files you upload to it and the javascript are allowed to XMLHttpRequest in that sandbox.
This is outside the control of the user. While had it been an app running locally, I could restrict network access or other resources.
Of course the web developer can chose to process the file client side only, but generally when you upload a file to a website, it gets uploaded and processed by their servers.
Surely you can verify this yourself while using the website, but I am confident that most users of a website wouldn't do that and be none the wiser how their data is being processed.
TLDR: I don't believe the average web user is capable of distinguishing a webapp that works in offline-only mode from a ordinary website.
In technical discussions, this is what I call "The Move". It comes from a desire to position the person making The Move as more knowledgeable and experienced and therefore correct and the other person as relatively new, inexperienced, lacking in wisdom, and naive. It's extremely sophomoric and perversely favored by those who lack the attributes they're trying to project. Don't do it.
I know how browsers and web apps work. I'm a former Mozillian, and among other things, I wrote, edited, and maintained the JS docs on developer.mozilla.org.
Even aside from The Move, nothing else that you wrote out here is especially relevant. The central observation I made is that users have more reason to be circumspect of non-browser based programs that they download and run than they do of browser-based programs because any nefarious thing a browser-based app can do, a native executable can do, too—or worse.
Anyone who has a gut feeling to the contrary is doing exactly that: operating on vibes and intuition and trying to reason with their gut instead of using actual reason to do what is ultimately a straightforward calculation.
(And the thing is, you and everyone else in your camp already knows the truths I've written out here. If you disagree, then we'll set aside one day a year that we'll call Native App Day. For Native App Day, browsers will refuse to execute browser-based apps. Instead everyone who publishes a web app will agree to publish programs packaged in the native executable format for Mac, Windows, and Linux, and everyone who typically uses the web app will run these executables with the same alacrity they apply when they undertake to use the web app. This will be strictly enforced, and there will be no cheating by folks who just refuse to use the computer on Native App Day.)
> In technical discussions, this is what I call "The Move". It comes from a desire to position the person making The Move as more knowledgeable and experienced and therefore correct and the other person as relatively new, inexperienced, lacking in wisdom, and naive. It's extremely sophomoric and perversely favored by those who lack the attributes they're trying to project. Don't do it.
Nonsense. Judging from your previous post it is apparent you are speaking outside of your expertise. Smearing labels all over rather than factually responding only makes it more so.
You claimed sandboxed browser apps was "more secure" than a traditional app.
Nobody suggested otherwise. In fact, we weren't discussing brower sandbox security model up to that point, but the differences between a online-only closed source web app and a traditional FOSS app.
> I know how browsers and web apps work.
So do the lot of us here, yet you don't seem to share a common understanding of the domain.
You do have a skewed understanding of the web app and seem to fail to understand why people would want a traditional app they could inspect and lock down as they please.
This suggest to me you are junior and/or suffering from a bit of Dunning Kruger because you might be skilled in other areas (in this case skilled in web dev and unskilled in traditional app dev), hence my previous comment about your skill level.
You responded to a lengthy post I made, and yet you fail to address any of the points raised.
> The central observation I made
.. was questioned by me and others and you just ignore what was said.
> And the thing is, you and everyone else in your camp already knows the truths I've written out here.
Get off your high horse.
You haven't shared shared any truths, you haven't addressed the issues we raised and you have a rather rude tone saying things like:
> You have made one of the most baffling logical errors that commonly crop up when people criticize browser-based apps.
And then continuing to fabricate intent.
(My point still stands).
It's a matter of habits. For me, Gimp is the primary image editing tool and all others feel alien.
When you open a non-Gimp file, for instance a PNG, and you want to update the source file, you need to "export" to PNG. And if you close the tab, Gimp warns you that your work isn't saved, because it hasn't been saved in its native xcf format. There is no way to know if the work has been saved to the original file. At least, that was the behavior at the time.
So I had opened a dozen of (versioned) PNG files, modified them, then overwritten the PNG files. On closing, Gimp warned me that none of the images was saved. I ignored the warning since I didn't want to track the changes in xcf files. It turned out one the files had not been "exported" to PNG.
Think of it like source code, and each exportable file type is like a compilation target.
You didn't lose data because of bad UI but because you are illiterate. You just said it, it warns you. If you can't understand what "none of the images was saved" means, there is no UI that can save you except autosave. But autosave is something you clearly don't want in a photo/image editor, even smartphone apps do not autosave photo edits.
Photoshop has autosave that works well, even for files with hundreds of layers, so it can be done. That being said, I can see that it's less useful when someone chooses not to save.
As for export, a single-layer file should be considered saved when one exports to lossless. A multi-layer file needs a different prompt, and I note Gimp has that now. It flags the file as "Exported to xxxxxx.png" in the Quit dialog.
This is the kind of dismissive posts thrown by people who haven't used gimp since 1999 and keep repeating the same lies every gimp release.
Affinity V2 Universal Licence For macOS, Windows & iPadOS
So there needs to be someone testing Gimp 3.0 against the previous version to see of any behaviors are not the same and sometimes that can affect workflows greatly!
But yes, please test and let us know - we'll be happy to look at it and fix as we can!
The wording here is confusing, because it makes it sound like CMYK/CIELAB will only be applied at the very end of the image transformation pipeline. That would really limit the usefulness of adding these extra color spaces, since doing the manipulation in a different color space than RGB is often the point.
But the linked blog post on GIMP.org[0] words it a little differently:
> What it means for color correctness in particular is that we will now do color conversion only when needed (last-second conversion) and therefore won’t lose information when it could have been avoided. For instance, say you color-pick color from an image: if we were to convert to an intermediate format, before using it on a second image (which may or may not be in another color format), we’d do 2 conversions. Which means more possibility of precision loss. The issue is even more flagrant if the input and output formats are the same (i.e. no conversion should happen at all). And this will be even more a problem when we will have core CMYK backend (we really want to avoid doing a round-trip to an intermediate format with CMYK, which doesn’t have bijective conversion with most other color models, even when working unbounded and ignoring precision issues).
That sounds more like the information of the original color space will be kept as well, and transformations will be applied only when necessary, to avoid lossy roundtrips. Which is not quite the same.
[0] https://www.gimp.org/news/2024/02/21/gimp-2-99-18-released/#...
The only colour space transformation that should happen when working with a CMYK image is when the image is displayed on screen. The CMYK data is interpreted with the attached colour profile (perhaps provided by the commercial printer I’m using) and then the colours are converted to RGB via my monitor’s profile and displayed on screen. None of these converted colours are ever saved in the file, and they need to be updated whenever any part of the image is altered (say using a dirty region -> repaint system).
Now if I do happen to open both a CMYK image and an RGB image and then try to copy and paste part of the RGB image into the CMYK one then a one-time conversion to CMYK needs to take place. Otherwise if I’m working only with CMYK images then no conversions should take place.
It sounds to me like the GIMP may have been written so that all of its operations are specialized to work with RGB pixels and so they cannot implement native editing on CMYK images without doing round trip conversions all over the place? If that’s the case then they need to buckle down and do the hard work of rewriting everything to be colour space independent.
I also want to note that Photoshop added CMYK support in version 2.0 which was released in 1991. This was before they even added layers! Photoshop was essentially designed for print almost from the very beginning. Having all the colour space stuff figured out before adding huge numbers of features was a major advantage. Trying to retrofit CMYK support into the GIMP seems like a bit of a nightmare.
Now all pixel data is stored in GeglColor objects, which contain the color model, space, and profile information in addition to pixel values. So you can just request, say, the 8bit CIE LAB or 16bit CMYK version of the pixel and retrieve it from the object.
I made a proof-of-concept CMYK mode for GIMP before this conversion was done - it would be even easier now. I hope to return to it and implement in GIMP proper in a near future release.
Good luck with the implementation of CMYK mode, I'm certain it will make GIMP a lot more attractive to many users!
(are CieLab and OKLab also being considered?)
The way to change projects is to write good code and work together with the other devs that made something you wanted to contribute to and then improve it together.
We are talking about GTK 3, right ?
" Why not be honest and resign yourself to the fact that version 0.8 is followed by version 0.8, which is then followed by version 0.8? " jwz
GIMP doesn't use GTK4.
"They" are a handful of maintainers doing relatively thankless work. This is not a well-paid full-time job for them.
Take Øyvind Kolås, the maintainer and lead developer of babl/GEGL, which is the technology underlying GIMP 3.0. He's barely being paid for this work. Nowadays he has a patreon, which also is directly linked from the gimp.org website, encouraging you to directly support him[0][1]. Right now those patreon donations add up to about... $1300 a month. And the number used to be much lower when I first started donating.
A lot of people here complain that we cannot directly give money to, say, the development Firefox. With GIMP you can directly support its core individual maintainer, and almost nobody does.
If you cannot / will not give money, you can also send patches: in most opensource projects, help is welcome
For instance, I worked on non-destructive editing because so many people said it was an essential missing feature that also needed to be there 20 years ago. Now that it's implemented, I've seen a lot of happy people who appreciate it and what it does for their workflow. At the same time, that means there are new requests for the next "essential missing feature". :)
And I can promise you, non-destructive editing was repeatedly requested by users, not just software developers. I have also seen a large number of users happy about the feature being implemented, as well as videos and screenshots of it being used effectively. It was a net positive in my opinion, even if there's more work to do in addition.
That's not to say your particular issue won't be addressed of course! You're just the first person I've seen to make that specific complaint, compared to the larger number of users asking for more CMYK support, shape tool, built-in Resynthesizer etc. What's been really nice about the RC1 release is that more members of the community are willing to try out 3.0 (compared to the various 2.99 releases) and give feedback. People use GIMP in lots of different ways, and if we don't use it in those ways then we don't see their specific problems.
This is because people with the complaint about text tend to open the software, see how bad moving text is, then close it and never open it again. They aren't the ones going onto your forums to complain. And when they do the bug stays open for 8 years (and counting) with the best response currently being to tell users that they're wrong for not knowing how to do it.
https://bugzilla.gnome.org/show_bug.cgi?id=768667 https://gitlab.gnome.org/GNOME/gimp/-/issues/933 https://gitlab.gnome.org/GNOME/gimp/-/issues/8399
However GIMP gets feedback from users, it's producing bad outcomes. Out of "CMYK support, shape tool, built-in Resynthesizer", I think users want a shape tool. But they'll get CMYK support. Here's the shape tool issue and it's 23 years old.
https://gitlab.gnome.org/GNOME/gimp/-/issues/12
Issue 12. Over 10,000 issues later and it hasn't been added. The existing solution to this is to select a shape and fill it. Why can they not add a tool which does both of these things in sequence? Again, perhaps a small change of code saves every new user of GIMP the annoyance of having to look up on google "how to draw circle in GIMP". Development should be prioritised in areas like this, where small changes to the code produce big wins in terms of UX. Instead, they focus on things like CMYK. I'm guessing that's a big change that won't affect most users. There's no point in developing these parts of the software if your UI has put off all the potential users. Look at Photopea, it has just one developer but eats GIMP's lunch on everything I just mentioned. GIMP needs to find a way of managing its devs to outdo a single person working on their own.
> I personally get inspiration for "big" projects to work on by scrolling various platforms and seeing what the most frequent complaints are, but that's not how development decisions are made.
A better approach would be to find someone who uses Photoshop, ask them to try GIMP, and record it. Then take the issues they ran into, and those are the most important things. If you want people to use any piece of software, you need to make them stick around long enough to actually do stuff in it, and that doesn't happen if the first thing they experience is bad. Basic things like they decided to put the button to search menus in a menu, so you might not be able to find it if you didn't already know it was there.
I've worked on 21+ year old issues, so I'm well aware of longstanding requests. For instance, I helped to implement built-in editable text outline options - another commonly searched for question about GIMP. The time we spent on that could have been spent on a number of other issues, and fixing each of those issues would have saved time for some users and annoyed others who'd prefer we'd work on something else.
Feedback from more users is always good, and I have watched Photoshop users work with GIMP. The immediate sticking points from those people were multi-selection, NDE, and a full CMYK mode - the text tool wasn't as big of a deal to those particular users as it is for you. That doesn't mean we don't want to make the UX better there, just that certain features are not equally important to everyone.
Also, you should implement a raster shape tool before you try to implement a vector one. You'll get the feature out much faster that way.
It's always easy to handwave away any complexities in a project you know nothing about. It'd be one thing if you had concrete criticisms rather than just going in circles about how you're generally unhappy to an overly patient volunteer, but if your only suggestion is "someone should figure out what's going on", you might as well say nothing.
I know that one of the behind-the-scenes things that Jehan (the maintainer) has been working on is establishing a foundation in partnership with GNOME. This will allow for easier methods of accepting donations, and developer grants to fund more sustained developer work. That obviously takes away from his coding time (and he's a much, much better programmer than I am!), but long term it will be very beneficial. Part of the GIMP 3.0 delay is due to those kinds of set-up work, where it's not immediately visible but will speed up future development.
For the shape tool, I think it'll be fairly quick once vector layers are implemented. At a high level, we'd just need to have some predefined vector layer shapes that users could manipulate. The functionality is there (one example: https://fosstodon.org/@CmykStudent/112063520232390856), the UI would be the sticking point.
more likely they just didn't feel as strongly about it as you do. difficult to move text is an inconvenience. and just to be clear, i have experienced the problem myself and got annoyed by it, but never annoyed enough that i would report an issue or look for alternative software. but lack of CMYK support or non-destructive editing are showstoppers that can't be worked around.
If the name was changed to something with less of an ick factor, contributors would double. (For anyone who believes the acronym is coincidental, it's confirmed to be inspired by "The Gimp" from Pulp Fiction. https://web.archive.org/web/20201111191926/https://www.xach....)
No they wouldn't. Most users of free and open source software don't contribute anything, regardless of the name or critical nature of the software they use, much less enough for developers to take a full time income for their work. And most users of GIMP couldn't care less about the name either way.
A good exercise is to imagine seeing a Show HN for the project RETARD or CRIPPLE, and how proud you'd be sharing the details of your work on RETARD with a prospective employer.
This is a step backward. Access to the window manager menu becomes difficult as a result.
I don't think I ever access that menu from the titlebar. But that's mostly because the unity DE is where I built most of my muscle memory.
After so many years I keep going back to it for quick edits.
After so many years I keep going back to it for quick edits.
It's not open source though so ¯\_(ツ)_/¯