I believe it's a step up from "design by whichever developer implemented a particular feature", which was the norm. :)
More seriously, we're trying to attract more designers and design feedback, just like we do for coding. We're also trying to document UX standards (see https://developer.gimp.org/core/ for early work) so there'll be a consistent experience as new developers join and features are added.
What version of GIMP are you running? Stable GIMP at this point (at least by our definition) is GIMP 3.2, which definitely has this feature. If you've been using 2.10 or earlier, then yeah, it wouldn't be in there.
Copy & Paste default behavior was changed in GIMP 3.0 (I was one of the people who worked on the change). GIMP 2.10 and earlier creating floating selections as described earlier.
I've gotten equal parts praise and complaints for working on that - some people think it makes GIMP much more intuitive, while others find it interfers with their workflow of quickly copying, editing, and merging back down pieces of a layer.
Non-destructive resize works on vector layers and link layers (essentially "smart objects" in GIMP). We have the capability to do this for regular layers too - just need to connect some things and change some internal assumptions about transform filters.
Possibly as part of our in-progress extension platform. The extension infrastructure is already built (e.g. you could package the theme as .gex file and have GIMP recognize it), and we have a GSoC student working on some aspects of it (at the moment, the submission workflow for an online repo of extensions). Once it's ready, we could reach out to the developers of PhotoGIMP and see if they'd be willing to have it included as part of the initial extensions repo - then you could pull it into GIMP directly.
We then discuss and test with the reporter and volunteer designers, and try to implement once some consensus has been reached. We welcome feedback from more users, so feel free to contribute your thoughts and design/workflow issues!
We want to make macros simpler (some of the work I helped out with for GIMP 3.0 was to lay the groundwork for automated/recordable operations), but as with all the things on our roadmap it takes time and developers.
And rectangles, triangles, and other custom shapes too I hope! :)
I'll do my best. I might actually finish cleaning up the code for the version in the video and post a WIP merge request so people can start trying it out and designing how the interactions should work.
That's up to you. Right now filters work the same way - you can merge them automatically on creation, merge them at some point while working, or merge them on export. For formats like PSD, we'll eventually add the option to export as non-destructive filters as well.
We don't want to take away choices - we just want to add more options for people's workflows.
Yes, it's planned for transform tools and already possible with filters. Technically our transform tools are already capable of this (they use GEGL operations the same as our non-destructive filters). We just need to tweak it to not immediately commit the transform, and then implement a UI.
That was a feature in GTK2 (the GUI library we use) that was removed in GTK3.
We could try to fight the library and reimplement it ourselves, but it'd take a developer dedicated to do it. I miss the menu icons too. :(
If you mean the color icons, you can easily switch back to those in the Welcome Dialog that appears when you first open GIMP (look in the Personalize tab). It's the first thing I do when I install GIMP on a new machine. :)
I can't speak for all of us, but generally no (in terms of GenAI at least). There are concerns about generated code not being compatible with GPL, and honestly a lot of the drive-by GenAI coded merge requests tend to not work.
The current non-destructive UI is a bit of a compromise - we can't really mix layers with NDE filters in the layer dock until GTK4 (from what I understand), so the pop-up menu is what we had to work with.
You can check "Merge filter" at the bottom of the filter dialogue though, and it will automatically merge the filter like in 2.10 (and the setting is remembered going forward)
Hi! What was the last version of GIMP that you used before 3.0?
We get an equal amount of "GIMP's UI never changes!" and "You changed too much of the UI in the latest version", so it's difficult sometimes to figure out the specific issues.
There's always the GFig filter, which has existed in GIMP for a long time. :)
GIMP 3.2 actually adds vector layers, which are the basis for a shape tool (it was my "big project" for this release). We have a GSoC project idea for doing the last bit of work to make a dedicated shape tool: https://developer.gimp.org/core/internship/ideas/#implement-...
It's because each transform was "destructive" (like filters use to be by default). What link & vector layers do instead is store a transform matrix, so each transform just updates the matrix instead of actually re-rasterizing the layer each time.
We were hoping to expand that feature to all layer types for 3.2, but we ran out of time to properly test it for release. It'll like be finished for the next minor release.
Do you happen to have a reference to GTK implementations of pie menus? The challenge we've run into is that newer versions of GTK "streamline" and remove features, so we have to either discard things or build our own replacement (as one example, we've received many complaints about icons no longer appearing in menus in GIMP 3.0, but that was due to the feature being basically removed in GTK3).
We currently have over 13,000 user-requested issues resolved in our issue tracker, so I don't think we're opposed to user requests. :)
I think that's a holdover from an earlier group of developers (there's been a lot of people coming and going in the 30 years that GIMP's been around!). We're also just limited by how fast we can implement certain things due to the number of developers. For instance, I focused on vector layers for GIMP 3.2 - a feature requested by many users! But that meant that I wasn't working on other features requested by other users.
More seriously, we're trying to attract more designers and design feedback, just like we do for coding. We're also trying to document UX standards (see https://developer.gimp.org/core/ for early work) so there'll be a consistent experience as new developers join and features are added.