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.
GIMP 3.0 is on the way
141–150 of 204 posts
Re: GIMP 3.0 is on the way
#142Earlier quoted context omitted.
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…
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"?
Re: GIMP 3.0 is on the way
#143I 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
Re: GIMP 3.0 is on the way
#144Earlier quoted context omitted.
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 managin…
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 ha…
> 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.
Re: GIMP 3.0 is on the way
#145I 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.
Re: GIMP 3.0 is on the way
#146I 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.
>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.
Re: GIMP 3.0 is on the way
#147Earlier quoted context omitted.
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.
Re: GIMP 3.0 is on the way
#148CMYK, finally. Hopefully this will lead to wider adoption, especially in the professional circles...
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.
Re: GIMP 3.0 is on the way
#149Earlier quoted context omitted.
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.
Re: GIMP 3.0 is on the way
#150CMYK, finally. Hopefully this will lead to wider adoption, especially in the professional circles...
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.