> GIMP 3.0 supports palettes outside of the "Standard Red Green Blue" (sRGB) range, such as "Cyan Magenta Yellow Key" (CMYK) and (CIELAB). This expanded color support, especially for CMYK, is essential to those who work with print and desktop publishing. However, GIMP continues to use sRGB, grayscale, and indexed colors for storing color information internally for now. Conversion to other color spaces is done on output, where necessary.
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.
This doesn’t make any sense to me. If I have 2 CMYK images open I should be able to colour pick and copy/paste between them and do any other sorts of manipulations with them without any colour space conversions taking place.
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.
Hi! That's actually what we were doing for GIMP 3.0. Originally, GIMP stored pixels in structs that just contained the pixel values (like GimpRGB's r, g, and b values).
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.
Yep - in fact, when discussing the idea for CMYK mode it was brought up that we should make it flexible for CieLab and other color modes. Unless someone beats me to it, I'll likely try to make a merge request with CMYK mode first, then use it as a reference commit for implementing other color models.
Finally updated UI! I really hope it inspires more updates and brings in even more people, just like when Blender revamped their UX a few years back and saw an amazing boost in popularity.
Does this change include any UX improvements? The article only mentions updated visuals and theming. From the discussions I've read, it's the UX of GIMP that holds it back.
It's just Photoshop addicts needing the UI to be identical to Photoshop because when they use GIMP their muscle memory is broken.
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.
Photoshop's UX is poor, but everyone is used to it. GIMP's UX is even worse, and nobody is used to it. And based on those screenshots in the article, it has, if anything, got even weirder and less intuitive.
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.
I'd say so. Non-destructive editing means you don't have to Ctrl-Z over and over again when you want to change a filter, which is a better user experience. Same with built-in text outline features, which makes that process much easier than in GIMP 2.10. Multi-selection instead of the chain tools is another nice UX improvement.
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.
I hate this buttons-in-the-title-bar thing with a passion. It takes ages to find a safe place to click and drag a window around without accidentally causing something else to happen.
With no disrespect to the blender team they are doing a bunch of good high quality ui work.
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.
Really looking forward to see more non-destructive editing. For me this has been one of the major reasons not to use GIMP in the past. The integration of GEGL is a huge milestone for GIMP imho.
How relevant is print these days ? Coming from that background it's depressing to see my former coworkers working in a shrinking market, and the only people in graphics I know that are making reasonable money are in digital.
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.
The reason they didn't use GIMP is because they couldn't use GIMP. It simply didn't have necessary capability. When I was working in prepress, I would have done anything to use GIMP. That desperation to escape Photoshop is why Affinity took off.
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.
I guess - of course it's a chicken-egg sort of a problem. No one's going to use it for print, before it has print-related capabilities - the same can be said for much of the UX, in general.
I think that was a typo in the article - GIMP is now "anyRGB". The color profile is associated with the RGB values, so you can load, work in, and export AdobeRGB, AppleRGB, etc.
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.
Professionals have no problem purchasing their work tools, and no reason to use subpar tools.
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?
It’s not the price, or even the fact that one has to pay. There are huge practical, security, and privacy reasons to never put closed-source software on your computer.
Sorry, not gonna buy into the paranoia that exists within every cult, including the FOSS cult. If your graphic design work has to be extremely secretive, then you'll do it on a machine without an internet connection. Do you think secretive companies like Apple or car manufacturers use GIMP for their graphical work? Of course not.
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.
Given enough resources, floss tools are often best in class. With your short-sighted attitude, Linux, Firefox, Blender, etc wouldn’t exist and we’d all be a lot poorer for it—fully controlled by the Oracles of the world without option.
FOSS tools are usually worst in class for the actual user, with some exceptions. The exceptions are generally dev tools and sys admin tools. Linux is not best in class in anything unless you're a developer or a server admin.
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.
If those new users report new problems, I think it's helpful for everyone. As an example, I helped add support for importing Adobe's ASE palettes into GIMP. Now that we have this feature, I just got a bug report for improving it. The reporter had a palette with a color model that we didn't have when testing it, and that sample enabled us to fix the import problem.
As I said, a very short-sighted attitude. Four dimensional thinking is harder but not hard. Also, you don’t seem to get the beer/freedom distinction.
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.
Short sighted is to believe that future generations can have the luxury of previous generations to live so extremely comfortably that they have ample free time and energy to make open source code (for the benefit of billion dollar companies mostly). I'd rather pay for quality apps, where I know that my money pays salaries for the developers. That is much more sustainable and far-sighted.
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?
I use Gimp from time to time, and often get frustrated with its... unique UI. It's nice to see they're hearing feedback and working on it :D
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.
> Websites[...] can sneakily copy the files you are working with
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.
i can remove network access capabilities from a desktop app after it is installed. i can't easily do that with an app running in a browser.
likewise monitoring and detecting network access per application is easy. tracking down which browser tab is making which network connection is a lot harder.
i am using that already. at least in firefox the network tab only shows which destinations generate traffic. it does not show which tab the traffic comes from. since any page can connect to multiple destinations, not just the one where the page is loaded from, this is not enough to identify the culprit.
you are not wrong on the comparison but you miss the tools available to contain a desktop application that are not available for a browser application. by default a browser application is more limited than a desktop application, but those limitations also reduce the possible functionality of a browser application, and they are locked in place as far as i am aware of.
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.
I am not sure about your level of computer literacy, so sorry in advance if I give a a overly detailed response.
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.
> I am not sure about your level of computer literacy, so sorry in advance if I give a a overly detailed response
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.)
>> I am not sure about your level of computer literacy, so sorry in advance if I give a a overly detailed response
> 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.
Krita works well for me on linux, but I get a lot of random crashes and weird graphics issues on Mac, It’s not worth it there for me. Not idea about windows.
There's habits sure, but GIMP also just has a lot of bad UI. For instance if you insert text, you have to click exactly on the black region of the character to select the text. This is really awkward because it means when you click on a letter to try and move some text, sometimes your click will go through the hole in the middle of the letter and select the thing behind the text. Also worth noting that this update is the one allowing people to edit rotated text and it took 20+ years. This is really bad UI/UX.
That's interesting. I have used and enjoyed a ton of software in different domains (from nothingreal shake to gnu ed) and so far gimp still wins the gold medals of triggering me. A rare feat.
Many years ago, I lost my work because of this "unique UI" and pledge never to use Gimp again, unless its behavior changed.
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.
This is standard behavior in pretty much any kind of art/content creation app. You have a project file which can be saved and reopened in the app, saving the state of the layers/effects/etc to be edited later, and can “export” a final render to a specific format for your medium. Image/video editing, digital audio workstations, 3D-modeling programs, they all behave like this, for good reason since it usually takes a long time to export to a specific format, and when you do, you lose the ability to change anything.
Think of it like source code, and each exportable file type is like a compilation target.
This is one of the weirder design changes that Gimp made, and it wasn't always that way. IIRC, the "save" option worked as you described in 2.0 but changed to the newer behaviour in either 2.2 or 2.4. Baffling because it really does change the workflow and coupled with the GTK+ load/save dialog boxes, it really has become much less intuitive than it used to be.
There is literally an "overwrite file" command in the file menu.
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.
autosave is useful for a file format of working files, like psd if non destructive changes are supported. But it would be stupid for exported end result format like jpeg, png, webp or pdf where changes cannot be recorded.
Yes, even though I never use photoshop and used Gimp for over 15 years it's a frustrating UI. I dislike it. Non destructive editing is a big upgrade though.
I also use Photopea from time to time. Can recommend.
If only a mad man would make a Photopea/Photoshop clone open source, then everyone (who has the skills) would be able to not only use a decent open source image editor, but one that can be fully customized to your needs.
> Congrats to the GIMP team, can't imagine the catharsis they will experience when 3.0 officially drops.
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:
Blender started ad in-house 3d modeling back in 1994, was open sourced in 2002, and continues with very active and sustainable development today. I used it most 2010-2012, and it has been incredible to see how much has happened since then.
Being old grows ecosystem. Lits of progress in N64 decompilation, & behind that is https://github.com/Fast-64/fast64 for using blender in romhack development
A vast, vast array of features. Multiple new renderers, material systems (lumping node systems into this), 2D animation systems (mostly via grease pencil AIUI), video compositing features, sculpting (I think is new since then?)
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.
Since no other pedants have chimed in yet, I'm required to point out that 20 years is five olympiads, which is the timespan in between six Olympic games.
There have been many many releases between 2.0 and 3.0. And many releases in the 2.99.x branch specifically.
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.
Yes, my comment was mostly meant tongue-in-cheek. I have my gripes about GIMPs UI but I have all the sympathy in the world for complicated updates taking a long time when done by volunteers, especially because they wanted to combine all plugin-breaking features into one release.
I remember "acquiring" Gimp in 2000 from a CD-ROM magazine as a child and using that for a good while until an uncle gave me a pirated copy of Photoshop 7. I actually disliked using Photoshop because I was so used to the way of doing things in Gimp.
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.
Does Gimp 3.0 still behave the same for GIF Animations and I use that feature extensively and the behavior for that needs to remain the same for cropping, scaling, and frame rates editing or I'll have remain on the older GIMP.
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!
Hi! I don't think there's been any specific changes for GIF animations, outside of improvements (like fixing a bug where overwriting a GIF animation without the GUI would lose the animation status, or adding the ability to import non-square pixel resolutions).
But yes, please test and let us know - we'll be happy to look at it and fix as we can!
I find it a bit weird that Gimp does not use the latest GTK (i.e. GTK4, which was considered stable since 2020), even though GTK originates in the Gimp project itself. It actually seems to be quite a bit behind: This is now the first release of Gimp which started to use GTK3, i.e. before, it even still used GTK2 (reached end-of-life in 2020)?
Having had to migrate a very simple project from GTK2 to GTK3, I don't think it's all that weird. The migration was utterly difficult, in the areas that hit me seemingly no effort was made to give proper migration paths. Only with some later published documentation (+ help from chatgpt) was it possible to restore some functionality later, after the initial migration. Finally that even meant calling the xlib directly.
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.
From what I've heard surrounding this, GTK3 to GTK4 isn't as big of a jump as GTK2 to GTK3 was. The GTK3 port was finished first because there was already work in place for that, but we can expect a GTK4 port to be faster.
That said, I haven't seen many apps that aren't specifically GNOME apps start using GTK4 in the first place, and as such I'm currently not using any GTK4 applications. I expect it to take a while before more things move to GTK4.
GTK stands for "Gnome first every other user literally does not matter break them hard, break them often, make them give up ToolKit" these days, and has for quite a while.
GTK4 removed a bunch of APIs for stupid reasons and GIMPs move to 3 started before 4 even existed. Had 4 at least tried to maintain some degree of compatibility then switching from 3 to 4 near the end would have been feasible. But that's not the case.
Qt also introduces some messy changes between major versions but they tend to be a lot more reasonable than what GTK does. Since Qt4 at least there's usually some attempt at providing alternatives for each deprecated function or class (the alternatives are shown in the error messages) and sometimes full-on compatibility layers for missing features are provided like with Qt5Compat.
Not sure Gimp devs would be willing to switch to C++ for Qt though.
I feel this. I tried using GTK4 a little while ago and almost immediately switched library when I realised it's simply incapable of doing certain things I needed, usually because either Wayland can't do it or GNOME doesn't need it.
Development ceased at the end of 2000, when Qt was released under the GPL, removing the perceived need for the Harmony Project to exist. In January 2009 Qt itself was made available under the GNU LGPL, along with the previous license options.
True but the leap from GTK2 to GTK3 is a lot bigger than from GTK3 to GTK4. I'm not sure when the "port" to GTK3 started, but if it was from before GTK4 was a thing, it makes sense that they wanted to finish the GTK3 stuff first.
Maybe so, but did you actually open that "on the radar" link? It was closed WONTFIX because moving to the latest release of their bespoke library was considered "tech debt" :-/ https://gitlab.gnome.org/GNOME/gimp/-/issues/6440#note_12726... I actually think it was terribly disingenuous of LWN to use "on the radar" language pointing at a closed issue. Maybe there is another issue (hiding in the 12,000 issues) that is actively tracking the Gtk4 migration, but that one ain't it
We actually had a Google Summer of Code project this summer that explored porting one of our main GTK3 widgets to be compatible with GTK4. It's definitely on our radar, but it's not a major focus at this point.
Do you have the correct issue that one could follow since 6440 isn't it?
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"?
If someone submitted a patch that ported everything in GIMP to GTK4, I'm quite sure it'd be accepted after review. The trouble is that GTK4 deprecates or breaks a number of things as well. For instance, while the icon scaling system is much more flexible in GTK4, it's different than in GTK3 so all that work would have to be redone. GtkTreeViews are also becoming obsolete, and since GIMP relies on that for the layer/path/channel views, it'll be another big change.
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.
I hope this doesn't lead distros to drop gtk2 libraries. There are still many programs beyond gimp that use them. But without a big name like gimp to justify their continued packaging we may lose them.
Surely there is no sane distro that would just YOLO a "Depends:" for an application, and what are depends declarations for except for dragging gtk2 or gtk0.59beta libraries in to support the requested install
Unfortunately, they seem to have moved to a different vendor for payment processing in the past year or two and now I get "The product you selected is not available in your location." Lucky me I still have V1 from a few years back, it's a shame though.
I got excited because I thought the headline meant it was out, but no, the first sentence says "3.0 is on the way" but given this project's release cadence that sentence could mean any number of time units
Valid point, but I will also amend your nitpick: Schwarz is also a name of a lot of people :) Both refer to hair colour, I think. "Schwartz" was a valid spelling for the colour many centuries ago (see, e.g., item 15 in [1]), which makes sense since both spellings are pronounced the same way. Surnames don't follow spelling changes, so that's the only situation in which both variants coexist now. In maths, you have the Cauchy-Schwarz inequality and Schwartz's theory of distributions.
Surely is key. The "key" plate in printing is the main plate with the most detail in the color separation, and it's typically black, hence key equals black.
I'm happy gIMP is still being worked on. That said, I'm a photoshop user and I find all my personal needs are covered by Photopea (https://photopea.com). It feels like it duplicates all of the photoshop features I regularly use including non-destructive editing, smart layers, and non-destructive layer blending options like stroke, outline, outer-shadow, inner-shadow, solid-color, that I use often. And it runs instantly on any machine I'm at
I'm told it's taken them two decades to release this essential feature. What have they been doing for all this time? I think they need to talk to people who edit photos, and focus their efforts on the many low-hanging fruit which would drastically improve the UX of their app (much like Blender did). Perhaps they are doing this to a degree, I see mentions of UI changes, but I wonder why they only think of it now and if they're involving the right people.
I was about to leave this as a top-level comment, but it might be more appropriate as a response to your question.
"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.
Would giving him more money improve the quality of his output? He also seems to not be in charge of the UI which is the major problem area. It's also worth noting that I could buy a subscription to Photoshop if we're talking about paying money to have software developed.
I get that this evangelism is useful, but it's also annoying. I'm also doing things with my life and I don't have the time to fix GIMP. My purpose in writing these comments is not to volunteer my time or money to the GIMP project, but to suggest they improve it by focusing on the many basic UI issues it has, which for some reason they haven't done in the last 20 years. Instead of laying the ground work for non-destructive editing, they should be making it so you can reliably click on text without selecting the thing behind.
The challenge is that there's only so many volunteers contributing to GIMP, and lots of people with requests. The loudest/most frequent ones tend to be addressed first (as volunteers are able).
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". :)
The idea that you can never make a good piece of software is backwards and wrong. There should come a point where your software has the essential features and reasonable UX. Producing software which does what the user wants without being actively hostile to them is the bare minimum. It doesn't take 20 years, it's not an endless process. If you spend 20 years doing it, you are managing your time badly. GIMP is managing their time badly. The "loudest/most frequent" requests is not a good metric to use because most of those issues are filed by software developers and not users.
To clarify, I wasn't talking about the developers' priorities as a whole. 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.
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.
> compared to the larger number of users asking for more CMYK support, shape tool, built-in Resynthesizer etc
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.
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.
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.
Actually, implementing vector layers and a shape tool is my next planned project after 3.0, so we'll hopefully get that first. :)
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.
And it's great that you're doing that, but what if you get hit by a bus? Does the issue just go back into the "never gonna happen" bin? Why do you think it took 20 years to get started on implementing this, and what have you done to ensure that won't happen again?
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.
I imagine another volunteer would come along, just like I did. That's the nature of an open source community project. Since I started, I've seen more developers join and work on their niche (building pipelines, text tool, plug-ins, etc).
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.
A foundation definitely seems like a solution here. It worked well for Blender. I just wonder if such a central organisation is truly necessary. Perhaps block-chain is the solution. /s At any rate, I'm glad to see GIMP is starting to take it's role as the flagship of FOSS more seriously.
This comment strikes me as non-constructive. What do you actually want this person to do? Clone themselves? Yes, gimp needs more people working on it to get features out faster. Berating the people actually doing the work until they also quit is certainly not helping
Well there are other people working on GIMP. Perhaps someone should look into what they've been doing for the past 20 years. It seems fairly unlikely to me that they didn't have time to do this, so there must be some other cause to the problem which it might be possible to address. And if the problem has already been solved, it might be good to know how that happened to avoid regressing back to the old state. I think it's productive to try and diagnose the cause of issues like this.
"Perhaps someone should audit these volunteers working on a project for free"
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 think they would be happy to participate in some kind of audit. They surely want to organise their contributions in such a way as to produce the most benefit to the project. As for suggesting someone figure it out, I don't know why it happens and I would like to know. This is why I ask. I think knowing could benefit others and potentially also benefit me.
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.
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.
Then I think you are the outlier. Most people who use GIMP for the first do so from the position of already having a (potentially non-legally obtained) copy of Photoshop. They are trying the software out and stuff like this quickly turns them off the idea of using it. If I had to guess, you use Linux and so don't have the option of Photoshop. This seems to be the case for most GIMP users.
> "They" are a handful of maintainers doing relatively thankless work. This is not a well-paid full-time job for them.
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....)
>If the name was changed to something with less of an ick factor, contributors would double.
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.
It's purely anecdotal if that wasn't clear. In my many conversations with folks where GIMP has been mentioned, the same two issues always come up: (1) the anachronistic user experience, and (2) the anachronistic name. Most of the people who could help with (1) aren't interested in a project with (2) on their CV.
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.
I fell for this before. Wasted a few weeks' free time adding thumbnails to the GTK file chooser, only to find out that the library itself has bugs which they refused to fix that make it difficult to do. Now I just have a patched version installed locally. The only way to improve these projects is to change how they're managed, which you can't do with a patch.
There is thumbnails support in the GTK4 file chooser now. That probably required shitloads of fixes in GTK, but now it works.
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.
I fundamentally disagree. The problem isn't that there were no thumbnails, but that it took decades to implement them. The cause of that problem can't seriously have been that people weren't programming hard enough. I think lots of code was likely written in that time. If we assume, as you seem to, that the issue was not enough code being written, then GTK would need to increase its count of contributors by 120 times to ship that feature in the span of two months. Your implication here is that it takes thousands of people multiple months to program a file chooser with thumbnails. I think one person should be able to do it in that time, and that the problem was something other than writing code. What has changed about the project to guarantee that the next important feature won't take 20 years to implement?
There were no thumbnails because no one wrote the necessary infrastructure before some one actually did. One person did most of the work and there were no other problems than actually writing code.
Okay, so what were all the other people doing? If it's one person's worth of work (as I suggested), and there was at least one person working on GIMP, why did they not do it? The fact that it was easy to do doesn't explain why it didn't happen. If anything, it makes it more mysterious. Unless you are genuinely telling me that there wasn't a single person working continuously on GTK for 20 years. It seems to me that they lack a process for deciding something needs to happen and then doing that thing.
The people who are doing the work, or a paying for the work, on GTK think that other tasks are more important or fun to do than the tasks you wish should be done. You might think that they are wrong and that other features are more important than a modern accessibility stack or whatever else the GTK devs have been doing, but the only way to change that is to actually engage in that project.
This is far from a personal opinion. It's probably the number one complaint about GTK, and it affects almost all software that runs on Linux since the GTK file chooser is often the default system file chooser. Almost all software opens a file at some point. Web browsers, chat clients, etc. Photos on user's computers rarely have meaningful names because they are often taken with a camera and the default image name isn't changed. This means that there has been no ergonomic way to open an image file on Linux for the past 20 years, and there still may not be for software that uses older versions of GTK. The accepted method is to open the system file browser and drag a file from that over into the application you need the file in. This has had an enormous cost to the reputation of all open source software.
> GIMP 3.0 supports palettes outside of the "Standard Red Green Blue" (sRGB) range, such as "Cyan Magenta Yellow Key" (CMYK) and (CIELAB). This expanded color support, especially for CMYK, is essential to those who work with print and desktop publishing. However, GIMP continues to use sRGB, grayscale, and indexed colors for storing color information internally for now. Conversion to other color spaces is done on output, where necessary.
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/#...
This doesn’t make any sense to me. If I have 2 CMYK images open I should be able to colour pick and copy/paste between them and do any other sorts of manipulations with them without any colour space conversions taking place.
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.
Hi! That's actually what we were doing for GIMP 3.0. Originally, GIMP stored pixels in structs that just contained the pixel values (like GimpRGB's r, g, and b values).
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.
You might want to send in a correction to the LWN article then, since the wording there is giving the wrong impression.
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?)
Yep - in fact, when discussing the idea for CMYK mode it was brought up that we should make it flexible for CieLab and other color modes. Unless someone beats me to it, I'll likely try to make a merge request with CMYK mode first, then use it as a reference commit for implementing other color models.
Finally updated UI! I really hope it inspires more updates and brings in even more people, just like when Blender revamped their UX a few years back and saw an amazing boost in popularity.
Does this change include any UX improvements? The article only mentions updated visuals and theming. From the discussions I've read, it's the UX of GIMP that holds it back.
It's just Photoshop addicts needing the UI to be identical to Photoshop because when they use GIMP their muscle memory is broken.
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.
Photoshop's UX is poor, but everyone is used to it. GIMP's UX is even worse, and nobody is used to it. And based on those screenshots in the article, it has, if anything, got even weirder and less intuitive.
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's UX was ok in 0.9, same with photoshop.
GIMP was meant to be a drop in replacement for early photoshop, so it makes sense that it follows that UX idea.
I'd say so. Non-destructive editing means you don't have to Ctrl-Z over and over again when you want to change a filter, which is a better user experience. Same with built-in text outline features, which makes that process much easier than in GIMP 2.10. Multi-selection instead of the chain tools is another nice UX improvement.
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.
I hope you can still configure it to have all the different toolboxes in separate windows like before.
Also who thought putting stuff like "Cancel" and "OK" into the title bar was a good idea?!
> 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.
I hate this buttons-in-the-title-bar thing with a passion. It takes ages to find a safe place to click and drag a window around without accidentally causing something else to happen.
> Also who thought putting stuff like "Cancel" and "OK" into the title bar was a good idea?!
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.
With no disrespect to the blender team they are doing a bunch of good high quality ui work.
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.
Yeah, but now it has the GNOME/GTK thing. I internally threw up upon seeing the screenshots.
Really looking forward to see more non-destructive editing. For me this has been one of the major reasons not to use GIMP in the past. The integration of GEGL is a huge milestone for GIMP imho.
is it possible to draw a circle without using a combination of 3 different tools?
I found a simple 8-step guide to draw a circle:
https://alvinalexander.com/gimp/gimp-how-to-create-draw-circ...
Please gimp devs, fix the basics
or move a selection on a layer without having to know a 3-key combination shortcut
"M"?
i just tried it, that seems to do nothing
the actual shortcut is ctrl + shift + L, btw
No, that kind of technology is still beyond us.
Use Inkscape for that.
I have to use Inkscape for rendering Devanagari text to import as SVG stroke paths in the Affinity Suite. Very annoying.
inkscape for pixel art?
or any other kind of geometric form, withouth going into path land, nope.
CMYK, finally. Hopefully this will lead to wider adoption, especially in the professional circles...
How relevant is print these days ? Coming from that background it's depressing to see my former coworkers working in a shrinking market, and the only people in graphics I know that are making reasonable money are in digital.
Not to say that it's irrelevant just that at this point it feels like it kind of missed the boat in this space.
> How relevant is print these days?
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.
I don't think anyone working in print would use Gimp, though?
The reason they didn't use GIMP is because they couldn't use GIMP. It simply didn't have necessary capability. When I was working in prepress, I would have done anything to use GIMP. That desperation to escape Photoshop is why Affinity took off.
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.
Naaah... For better or worse we're all set up with our Adobe Creative Clouds...
The Affinity suite - now for $80 due to Black Friday - is a viable competitor to Photoshop for many applications. It's much better than Gimp.
That's true, I got one myself, but as everybody is educated and trained on Adobe products switching is not that easy.
why is that though? isn't that the bulk of the criticism? bad UX and lack of features needed for print?
I guess - of course it's a chicken-egg sort of a problem. No one's going to use it for print, before it has print-related capabilities - the same can be said for much of the UX, in general.
CMYK is not so important now, but Lab IS.
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.
I think that was a typo in the article - GIMP is now "anyRGB". The color profile is associated with the RGB values, so you can load, work in, and export AdobeRGB, AppleRGB, etc.
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.
Professionals have no problem purchasing their work tools, and no reason to use subpar tools.
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?
It’s not the price, or even the fact that one has to pay. There are huge practical, security, and privacy reasons to never put closed-source software on your computer.
Sorry, not gonna buy into the paranoia that exists within every cult, including the FOSS cult. If your graphic design work has to be extremely secretive, then you'll do it on a machine without an internet connection. Do you think secretive companies like Apple or car manufacturers use GIMP for their graphical work? Of course not.
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.
Given enough resources, floss tools are often best in class. With your short-sighted attitude, Linux, Firefox, Blender, etc wouldn’t exist and we’d all be a lot poorer for it—fully controlled by the Oracles of the world without option.
FOSS tools are usually worst in class for the actual user, with some exceptions. The exceptions are generally dev tools and sys admin tools. Linux is not best in class in anything unless you're a developer or a server admin.
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.
If those new users report new problems, I think it's helpful for everyone. As an example, I helped add support for importing Adobe's ASE palettes into GIMP. Now that we have this feature, I just got a bug report for improving it. The reporter had a palette with a color model that we didn't have when testing it, and that sample enabled us to fix the import problem.
As I said, a very short-sighted attitude. Four dimensional thinking is harder but not hard. Also, you don’t seem to get the beer/freedom distinction.
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.
Short sighted is to believe that future generations can have the luxury of previous generations to live so extremely comfortably that they have ample free time and energy to make open source code (for the benefit of billion dollar companies mostly). I'd rather pay for quality apps, where I know that my money pays salaries for the developers. That is much more sustainable and far-sighted.
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?
I use Gimp from time to time, and often get frustrated with its... unique UI. It's nice to see they're hearing feedback and working on it :D
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 would recommend Krita instead of a website.
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.
https://krita.org/en/
> Websites[...] can sneakily copy the files you are working with
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.
i can remove network access capabilities from a desktop app after it is installed. i can't easily do that with an app running in a browser.
likewise monitoring and detecting network access per application is easy. tracking down which browser tab is making which network connection is a lot harder.
Go to the network tab of your browser's dev tools. It's literally easier than with a desktop app.
i am using that already. at least in firefox the network tab only shows which destinations generate traffic. it does not show which tab the traffic comes from. since any page can connect to multiple destinations, not just the one where the page is loaded from, this is not enough to identify the culprit.
You are either confused about something, or you're simply refusing to engage with reality.
> Any nefarious thing a browser-based app can do, a local program can do, too, [or worse!]
you are not wrong on the comparison but you miss the tools available to contain a desktop application that are not available for a browser application. by default a browser application is more limited than a desktop application, but those limitations also reduce the possible functionality of a browser application, and they are locked in place as far as i am aware of.
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.
I am not sure about your level of computer literacy, so sorry in advance if I give a a overly detailed response.
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.
> I am not sure about your level of computer literacy, so sorry in advance if I give a a overly detailed response
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.)
>> I am not sure about your level of computer literacy, so sorry in advance if I give a a overly detailed response
> 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).
K.
> require internet access It's a PWA and works offline perfectly.
Krita works well for me on linux, but I get a lot of random crashes and weird graphics issues on Mac, It’s not worth it there for me. Not idea about windows.
Krita is more geared toward digital drawing than image processing, I recommend Affinity Photo
> frustrated with its... unique UI
It's a matter of habits. For me, Gimp is the primary image editing tool and all others feel alien.
There's habits sure, but GIMP also just has a lot of bad UI. For instance if you insert text, you have to click exactly on the black region of the character to select the text. This is really awkward because it means when you click on a letter to try and move some text, sometimes your click will go through the hole in the middle of the letter and select the thing behind the text. Also worth noting that this update is the one allowing people to edit rotated text and it took 20+ years. This is really bad UI/UX.
That's interesting. I have used and enjoyed a ton of software in different domains (from nothingreal shake to gnu ed) and so far gimp still wins the gold medals of triggering me. A rare feat.
Many years ago, I lost my work because of this "unique UI" and pledge never to use Gimp again, unless its behavior changed.
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.
This is standard behavior in pretty much any kind of art/content creation app. You have a project file which can be saved and reopened in the app, saving the state of the layers/effects/etc to be edited later, and can “export” a final render to a specific format for your medium. Image/video editing, digital audio workstations, 3D-modeling programs, they all behave like this, for good reason since it usually takes a long time to export to a specific format, and when you do, you lose the ability to change anything.
Think of it like source code, and each exportable file type is like a compilation target.
Think of it more like GIMP chasing non-existent users while ignoring the workflow of its actual users.
This is one of the weirder design changes that Gimp made, and it wasn't always that way. IIRC, the "save" option worked as you described in 2.0 but changed to the newer behaviour in either 2.2 or 2.4. Baffling because it really does change the workflow and coupled with the GTK+ load/save dialog boxes, it really has become much less intuitive than it used to be.
There is literally an "overwrite file" command in the file menu.
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.
That's a rude and somewhat inaccurate response.
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.
autosave is useful for a file format of working files, like psd if non destructive changes are supported. But it would be stupid for exported end result format like jpeg, png, webp or pdf where changes cannot be recorded.
Yes, even though I never use photoshop and used Gimp for over 15 years it's a frustrating UI. I dislike it. Non destructive editing is a big upgrade though.
I also use Photopea from time to time. Can recommend.
If only a mad man would make a Photopea/Photoshop clone open source, then everyone (who has the skills) would be able to not only use a decent open source image editor, but one that can be fully customized to your needs.
I've loaded photopea, krita and gimp side by side and really there are absolutely no major differences in UI.
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.
Have you tried Krita yet?
I like using pinta for the "easy" cases.
I don't use any photo editing tool but I know there is photogimp which makes gimp look like photoshop.
I started using GIMP around 2003 as a small child, and I remember being hyped for 3.0 and non-destructive editing even back then.
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.
> Congrats to the GIMP team, can't imagine the catharsis they will experience when 3.0 officially drops.
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:
https://en.wikipedia.org/wiki/The_Tortoise_and_the_Hare
>Any other open-source software that has a comparable development time that I'm not aware of?
GNOME famously had that file picker thumbnail issue open for 18 years.
https://www.omglinux.com/gnome-thumbnails-file-picker/
Blender started ad in-house 3d modeling back in 1994, was open sourced in 2002, and continues with very active and sustainable development today. I used it most 2010-2012, and it has been incredible to see how much has happened since then.
https://www.blender.org/about/history/
What's been added since then?
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?
Being old grows ecosystem. Lits of progress in N64 decompilation, & behind that is https://github.com/Fast-64/fast64 for using blender in romhack development
A vast, vast array of features. Multiple new renderers, material systems (lumping node systems into this), 2D animation systems (mostly via grease pencil AIUI), video compositing features, sculpting (I think is new since then?)
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.
Since no other pedants have chimed in yet, I'm required to point out that 20 years is five olympiads, which is the timespan in between six Olympic games.
> Any other open-source software that has a comparable development time that I'm not aware of?
Emacs. Free and open source. User software. 40 (50) years in development. Mythical
not sure if i would call taking 20 years for a release "steady"
There have been many many releases between 2.0 and 3.0. And many releases in the 2.99.x branch specifically.
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.
Yes, my comment was mostly meant tongue-in-cheek. I have my gripes about GIMPs UI but I have all the sympathy in the world for complicated updates taking a long time when done by volunteers, especially because they wanted to combine all plugin-breaking features into one release.
That's as steady as she gets, baby.
Congrats to the GIMP team for being more spry than the HURD team ;)
I remember "acquiring" Gimp in 2000 from a CD-ROM magazine as a child and using that for a good while until an uncle gave me a pirated copy of Photoshop 7. I actually disliked using Photoshop because I was so used to the way of doing things in Gimp.
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...
>Slow and steady wins the race.
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.
I too used GIMP as a kid, but alas I am somewhat older.
Its great to see it improving, and adding big things like CMYK
Indeed, you can't hurry v3.
angry Python noises
I remember getting a copy of the Motif-based GIMP for AIX sometime in 1996 or so.
I remember when the GIMP crew threw a conniption fit over the Qt port.
Does Gimp 3.0 still behave the same for GIF Animations and I use that feature extensively and the behavior for that needs to remain the same for cropping, scaling, and frame rates editing or I'll have remain on the older GIMP.
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!
Sounds like you would be great at it since you know the feature inside-out! You can download the RCs and send bug reports.
Hi! I don't think there's been any specific changes for GIF animations, outside of improvements (like fixing a bug where overwriting a GIF animation without the GUI would lose the animation status, or adding the ability to import non-square pixel resolutions).
But yes, please test and let us know - we'll be happy to look at it and fix as we can!
I find it a bit weird that Gimp does not use the latest GTK (i.e. GTK4, which was considered stable since 2020), even though GTK originates in the Gimp project itself. It actually seems to be quite a bit behind: This is now the first release of Gimp which started to use GTK3, i.e. before, it even still used GTK2 (reached end-of-life in 2020)?
Having had to migrate a very simple project from GTK2 to GTK3, I don't think it's all that weird. The migration was utterly difficult, in the areas that hit me seemingly no effort was made to give proper migration paths. Only with some later published documentation (+ help from chatgpt) was it possible to restore some functionality later, after the initial migration. Finally that even meant calling the xlib directly.
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.
From what I've heard surrounding this, GTK3 to GTK4 isn't as big of a jump as GTK2 to GTK3 was. The GTK3 port was finished first because there was already work in place for that, but we can expect a GTK4 port to be faster. That said, I haven't seen many apps that aren't specifically GNOME apps start using GTK4 in the first place, and as such I'm currently not using any GTK4 applications. I expect it to take a while before more things move to GTK4.
GTK stands for "Gnome first every other user literally does not matter break them hard, break them often, make them give up ToolKit" these days, and has for quite a while.
The funniest thing is that GTK used to stand for "Gimp toolkit". How times fly.
GTK4 removed a bunch of APIs for stupid reasons and GIMPs move to 3 started before 4 even existed. Had 4 at least tried to maintain some degree of compatibility then switching from 3 to 4 near the end would have been feasible. But that's not the case.
If you aren't Gnome, GTK is not for you.
Might as well port the next version of Gimp to Qt - they seem to be much more reasonable as API providers.
Qt also introduces some messy changes between major versions but they tend to be a lot more reasonable than what GTK does. Since Qt4 at least there's usually some attempt at providing alternatives for each deprecated function or class (the alternatives are shown in the error messages) and sometimes full-on compatibility layers for missing features are provided like with Qt5Compat.
Not sure Gimp devs would be willing to switch to C++ for Qt though.
I feel this. I tried using GTK4 a little while ago and almost immediately switched library when I realised it's simply incapable of doing certain things I needed, usually because either Wayland can't do it or GNOME doesn't need it.
Would you care to actually list those things?
Guess what the "G" in GTK stands for historically
That was before GNOME took over, as it was supposed to be the answer against KDE and original Qt license.
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.
I think Harmony was the Qt replacement but I don’t think it lasted very long.
That was after Nokia acquisition from Trolltech.
https://blogs.kde.org/2009/01/14/cute-harmony-qt-goes-lgpl/
Development ceased at the end of 2000, when Qt was released under the GPL, removing the perceived need for the Harmony Project to exist. In January 2009 Qt itself was made available under the GNU LGPL, along with the previous license options.
True but the leap from GTK2 to GTK3 is a lot bigger than from GTK3 to GTK4. I'm not sure when the "port" to GTK3 started, but if it was from before GTK4 was a thing, it makes sense that they wanted to finish the GTK3 stuff first.
> I'm not sure when the "port" to GTK3 started
Probably more than 10 years ago.
GTK 3.0 was released in 2011 and it was announced a few years before that, probably in 2009. So whoever down voted, the 90s weren't 10 years ago...
From the second paragraph of the article:
> 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.
Maybe so, but did you actually open that "on the radar" link? It was closed WONTFIX because moving to the latest release of their bespoke library was considered "tech debt" :-/ https://gitlab.gnome.org/GNOME/gimp/-/issues/6440#note_12726... I actually think it was terribly disingenuous of LWN to use "on the radar" language pointing at a closed issue. Maybe there is another issue (hiding in the 12,000 issues) that is actively tracking the Gtk4 migration, but that one ain't it
We actually had a Google Summer of Code project this summer that explored porting one of our main GTK3 widgets to be compatible with GTK4. It's definitely on our radar, but it's not a major focus at this point.
Do you have the correct issue that one could follow since 6440 isn't it?
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"?
If someone submitted a patch that ported everything in GIMP to GTK4, I'm quite sure it'd be accepted after review. The trouble is that GTK4 deprecates or breaks a number of things as well. For instance, while the icon scaling system is much more flexible in GTK4, it's different than in GTK3 so all that work would have to be redone. GtkTreeViews are also becoming obsolete, and since GIMP relies on that for the layer/path/channel views, it'll be another big change.
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.
GTK has become the Gnome toolkit , and the Gnome developers don't care about developers outside their umbrella.
> I find it a bit weird that Gimp does not use the latest GTK
Which is ? GTK 6 ? GTK is a moving target (like a lot of libraries those days). /s
I used GIMP earlier today. So thank you all involved!
After so many years I keep going back to it for quick edits.
I hope this doesn't lead distros to drop gtk2 libraries. There are still many programs beyond gimp that use them. But without a big name like gimp to justify their continued packaging we may lose them.
Surely there is no sane distro that would just YOLO a "Depends:" for an application, and what are depends declarations for except for dragging gtk2 or gtk0.59beta libraries in to support the requested install
Yeah. I thought the same thing before it happened to the gtk1 libs and the programs I used to use (xmms, etc) stopped being supported generally.
affinity is the best one: https://affinity.serif.com
Affinity V2 Universal Licence For macOS, Windows & iPadOS
Doesn't seem to be open source: https://opensource.org/licenses?ls=affinity
Not open source, but too good for a few bucks...
Unfortunately, they seem to have moved to a different vendor for payment processing in the past year or two and now I get "The product you selected is not available in your location." Lucky me I still have V1 from a few years back, it's a shame though.
Affinity is good but it's a shame they don't have a Linux version.
To run on Linux: https://forum.affinity.serif.com/index.php?/topic/182758-aff...
Gimp seems way to complicated still. I played around with krita, it's way better for what I do.
> this release has transitioned to using GTK's header bar component, typically used to combine an application's toolbar and title bar into one unit
This is a step backward. Access to the window manager menu becomes difficult as a result.
Do you mean the menu you get from holding super and right clicking on the window?
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.
I got excited because I thought the headline meant it was out, but no, the first sentence says "3.0 is on the way" but given this project's release cadence that sentence could mean any number of time units
CMYK - the K is Klein, or black. Surely not key? Or has something changed?
Klein? that means small. Schwartz is black
mini-nitpick for everyone that might be confused: it's "schwarz" (without t), Schwartz is a name of a lot of people.
Valid point, but I will also amend your nitpick: Schwarz is also a name of a lot of people :) Both refer to hair colour, I think. "Schwartz" was a valid spelling for the colour many centuries ago (see, e.g., item 15 in [1]), which makes sense since both spellings are pronounced the same way. Surnames don't follow spelling changes, so that's the only situation in which both variants coexist now. In maths, you have the Cauchy-Schwarz inequality and Schwartz's theory of distributions.
[1] https://woerterbuchnetz.de/?sigle=DWB&lemid=S04549
It's a pity there's no schwarz-schwartz like there is Lorenz-lorentz
I completely stand corrected.
Surely is key. The "key" plate in printing is the main plate with the most detail in the color separation, and it's typically black, hence key equals black.
I'm happy gIMP is still being worked on. That said, I'm a photoshop user and I find all my personal needs are covered by Photopea (https://photopea.com). It feels like it duplicates all of the photoshop features I regularly use including non-destructive editing, smart layers, and non-destructive layer blending options like stroke, outline, outer-shadow, inner-shadow, solid-color, that I use often. And it runs instantly on any machine I'm at
It's not open source though so ¯\_(ツ)_/¯
because of the unpleasant name of the app (which the devs refuse to change), lets normalise pronouncing the G in GIMP like the G in GIF...
I see what you did there
Gimp pronounced like jimp? Might save this disgusting name.
And thus the Gimp-Jimp wars began, even more brutal than the XEmacs-GNUEmacs wars.
[dead]
[flagged]
Wasn't there already a fork that changed the name?
[flagged]
I'm told it's taken them two decades to release this essential feature. What have they been doing for all this time? I think they need to talk to people who edit photos, and focus their efforts on the many low-hanging fruit which would drastically improve the UX of their app (much like Blender did). Perhaps they are doing this to a degree, I see mentions of UI changes, but I wonder why they only think of it now and if they're involving the right people.
I was about to leave this as a top-level comment, but it might be more appropriate as a response to your question.
"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.
[0] https://www.patreon.com/c/pippin/membership
[1] https://www.gimp.org/donating/
Would giving him more money improve the quality of his output? He also seems to not be in charge of the UI which is the major problem area. It's also worth noting that I could buy a subscription to Photoshop if we're talking about paying money to have software developed.
If you want to be a whiny customer then pay for commercial software and post your comments on their user forums, what are you doing here?
And if GIMP's proposition to its users is "you should use Photoshop instead", do you see why it won't succeed?
With more money, he could leave his daily job and work full time on GIMP
If you cannot / will not give money, you can also send patches: in most opensource projects, help is welcome
I get that this evangelism is useful, but it's also annoying. I'm also doing things with my life and I don't have the time to fix GIMP. My purpose in writing these comments is not to volunteer my time or money to the GIMP project, but to suggest they improve it by focusing on the many basic UI issues it has, which for some reason they haven't done in the last 20 years. Instead of laying the ground work for non-destructive editing, they should be making it so you can reliably click on text without selecting the thing behind.
The challenge is that there's only so many volunteers contributing to GIMP, and lots of people with requests. The loudest/most frequent ones tend to be addressed first (as volunteers are able).
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". :)
The idea that you can never make a good piece of software is backwards and wrong. There should come a point where your software has the essential features and reasonable UX. Producing software which does what the user wants without being actively hostile to them is the bare minimum. It doesn't take 20 years, it's not an endless process. If you spend 20 years doing it, you are managing your time badly. GIMP is managing their time badly. The "loudest/most frequent" requests is not a good metric to use because most of those issues are filed by software developers and not users.
To clarify, I wasn't talking about the developers' priorities as a whole. 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.
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.
> compared to the larger number of users asking for more CMYK support, shape tool, built-in Resynthesizer etc
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.
Actually, implementing vector layers and a shape tool is my next planned project after 3.0, so we'll hopefully get that first. :)
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.
And it's great that you're doing that, but what if you get hit by a bus? Does the issue just go back into the "never gonna happen" bin? Why do you think it took 20 years to get started on implementing this, and what have you done to ensure that won't happen again?
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.
I imagine another volunteer would come along, just like I did. That's the nature of an open source community project. Since I started, I've seen more developers join and work on their niche (building pipelines, text tool, plug-ins, etc).
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.
A foundation definitely seems like a solution here. It worked well for Blender. I just wonder if such a central organisation is truly necessary. Perhaps block-chain is the solution. /s At any rate, I'm glad to see GIMP is starting to take it's role as the flagship of FOSS more seriously.
This comment strikes me as non-constructive. What do you actually want this person to do? Clone themselves? Yes, gimp needs more people working on it to get features out faster. Berating the people actually doing the work until they also quit is certainly not helping
Well there are other people working on GIMP. Perhaps someone should look into what they've been doing for the past 20 years. It seems fairly unlikely to me that they didn't have time to do this, so there must be some other cause to the problem which it might be possible to address. And if the problem has already been solved, it might be good to know how that happened to avoid regressing back to the old state. I think it's productive to try and diagnose the cause of issues like this.
"Perhaps someone should audit these volunteers working on a project for free"
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 think they would be happy to participate in some kind of audit. They surely want to organise their contributions in such a way as to produce the most benefit to the project. As for suggesting someone figure it out, I don't know why it happens and I would like to know. This is why I ask. I think knowing could benefit others and potentially also benefit me.
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.
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.
Then I think you are the outlier. Most people who use GIMP for the first do so from the position of already having a (potentially non-legally obtained) copy of Photoshop. They are trying the software out and stuff like this quickly turns them off the idea of using it. If I had to guess, you use Linux and so don't have the option of Photoshop. This seems to be the case for most GIMP users.
> "They" are a handful of maintainers doing relatively thankless work. This is not a well-paid full-time job for them.
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....)
>If the name was changed to something with less of an ick factor, contributors would double.
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.
That's quite an assertion to make, probably without evidence?
It's purely anecdotal if that wasn't clear. In my many conversations with folks where GIMP has been mentioned, the same two issues always come up: (1) the anachronistic user experience, and (2) the anachronistic name. Most of the people who could help with (1) aren't interested in a project with (2) on their CV.
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.
https://developer.gimp.org/core/submit-patch/
I fell for this before. Wasted a few weeks' free time adding thumbnails to the GTK file chooser, only to find out that the library itself has bugs which they refused to fix that make it difficult to do. Now I just have a patched version installed locally. The only way to improve these projects is to change how they're managed, which you can't do with a patch.
There is thumbnails support in the GTK4 file chooser now. That probably required shitloads of fixes in GTK, but now it works.
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.
I fundamentally disagree. The problem isn't that there were no thumbnails, but that it took decades to implement them. The cause of that problem can't seriously have been that people weren't programming hard enough. I think lots of code was likely written in that time. If we assume, as you seem to, that the issue was not enough code being written, then GTK would need to increase its count of contributors by 120 times to ship that feature in the span of two months. Your implication here is that it takes thousands of people multiple months to program a file chooser with thumbnails. I think one person should be able to do it in that time, and that the problem was something other than writing code. What has changed about the project to guarantee that the next important feature won't take 20 years to implement?
There were no thumbnails because no one wrote the necessary infrastructure before some one actually did. One person did most of the work and there were no other problems than actually writing code.
Okay, so what were all the other people doing? If it's one person's worth of work (as I suggested), and there was at least one person working on GIMP, why did they not do it? The fact that it was easy to do doesn't explain why it didn't happen. If anything, it makes it more mysterious. Unless you are genuinely telling me that there wasn't a single person working continuously on GTK for 20 years. It seems to me that they lack a process for deciding something needs to happen and then doing that thing.
The people who are doing the work, or a paying for the work, on GTK think that other tasks are more important or fun to do than the tasks you wish should be done. You might think that they are wrong and that other features are more important than a modern accessibility stack or whatever else the GTK devs have been doing, but the only way to change that is to actually engage in that project.
This is far from a personal opinion. It's probably the number one complaint about GTK, and it affects almost all software that runs on Linux since the GTK file chooser is often the default system file chooser. Almost all software opens a file at some point. Web browsers, chat clients, etc. Photos on user's computers rarely have meaningful names because they are often taken with a camera and the default image name isn't changed. This means that there has been no ergonomic way to open an image file on Linux for the past 20 years, and there still may not be for software that uses older versions of GTK. The accepted method is to open the system file browser and drag a file from that over into the application you need the file in. This has had an enormous cost to the reputation of all open source software.
People complained but nobody put in enough work to get a good solution until someone actually did.
> There were no thumbnails because no one wrote the necessary infrastructure before some one actually did.
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
I don't get you comment here.
> There is thumbnails support in the GTK4 file chooser now.
GIMP doesn't use GTK4.
If I see a helicopter that crashed down on a tree, I can say something is wrong even if I don't have license for flying.
If you had to elbow your way trough a big crowd to actually see the crash, positing "A crash!" on social media is not an useful service for anyone.
Possibly true, but it doesn't mean you can talk about the competency of the pilot(s), either.