GNOME Bugzilla – Bug 792470
Some filters e.g. "Levels" are not added to "Repeat last" history
Last modified: 2018-05-24 19:01:46 UTC
I love that I can hit ctrl-f and re-do the last hue-saturation filter without having to go through the dialog again! I use that feature all the time, so I noticed that some other colour filters do not get saved to the Ctrl-f Repeat history buffer. Mitch has asked me to file this bug report for his reminder. :) I tested all the items under Colours and Filters and the following did not show up in the Repeat buffer after they were used: Colours > Brightness/Contrast Colours > Levels Colours > Curves Colours > Auto > Equalise Colours > Auto > White Balance Colours > Threshold... Thanks for looking into it! -C
The stuff in "Auto" is a bit special, will hopefully find a solution for these too. The rest are simply the remaining old "real" color tools that can't be trivially converted to something that can be ran in GimpOperationTool. They should however be invoked using the standard filter-actions/commands mechanism, so they end up in "Recently used" automatically.
This fixes the important part of the four remaining classic color tools: commit b23f231a1ae36ea90b5822f6769fd55c07ec9c53 Author: Michael Natterer <mitch@gimp.org> Date: Sun Jan 14 15:42:29 2018 +0100 Bug 792470 - Some filters e.g. "Levels" are not added to "Repeat last" history The four remaining "classic" color tools (Brightness-Contrast, Curves, Levels and Threshold) are in fact just special UIs for otherwise completely normal filter ops. Add normal filter actions for them and invoke them like all other filters, which makes them show up in the filter history automatically. The only small hack needed is to special case them in gimp_gegl_procedure_execute_async() so the right tools are created instead of the default GimpOperationTool. Also, blacklist the automatically generated tools actions from action search and the shortcut editor. app/actions/filters-actions.c | 24 ++++++++++ app/actions/gimpgeglprocedure.c | 56 +++++++++++++++++------- app/operations/gimpoperationbrightnesscontrast.c | 4 +- app/operations/gimpoperationcurves.c | 4 +- app/operations/gimpoperationlevels.c | 4 +- app/operations/gimpoperationthreshold.c | 2 +- app/tools/gimpbrightnesscontrasttool.c | 2 +- app/tools/gimpcurvestool.c | 2 +- app/tools/gimplevelstool.c | 2 +- app/tools/gimpthresholdtool.c | 2 +- app/widgets/gimpaction.c | 14 ++++++ menus/image-menu.xml.in | 8 ++-- po/POTFILES.in | 3 ++ 13 files changed, 99 insertions(+), 28 deletions(-)
Since commit b23f231a1ae36ea90b5822f6769fd55c07ec9c53 it now takes something like five clicks to reset Levels back to the previously default "no change" settings. Each channel needs to be reset individually, which means resetting the Value Channel, and then clicking to access the Red Channel, and resetting it, and so forth with the Green and Blue Channels. Then there's an additional click to reset to use Linear vs Gamma, if that's been changed from the default, and possibly also resetting stuff hidden inside the Advanced drop-down menu. Is this the intended final behavior? Because currently this is far too many clicks to get back to "no change until the user actually starts deliberately moving sliders". There has always been the option to retrieve the last-used Levels settings by clicking on the Presets drop-down menu, without any need to individually reset all the channels if the last-used Levels settings isn't actually the desired settings. Similar numbers of clicks are also needed for Curves except in the sole case of where the user actually does want to use the last-used Curves settings, and again, in this case the Presets menu for the last-used settings is just one click away. For Hue-Chroma, only one click is needed to reset the sliders, but it's bothersome to have to *always* hit "reset" before starting to move the sliders. I can't think of any remotely common use case where a user would actually want to repetitively make the exact same Hue-Chroma adjustments, leastways not in a photographic or digital painting workflow. Is there a possibility to provide for the option that *all* items on Colors menu would always reset themselves automatically to "no change", and still provide for "last used" via the Presets drop-down?
*** Bug 792905 has been marked as a duplicate of this bug. ***
The few remaining individual color tools now simply behave like all other filters. Pro: consistency Contra: is this wanted at all? I don't think we can go "let's have the new behavior for all filters which look like former plug-ins, but have the old behavior for things that always were tools". Perhaps we need a global config boolean to enable/disable this, or simply not do it at all, as you say there is always the menu of recently used settings. Also, you say you have to click at least 5 times, is the global reset button at the bottom of the dialog not working properly? That would be one click only.
(In reply to Michael Natterer from comment #5) > Also, you say you have to click at least 5 times, is the global > reset button at the bottom of the dialog not working properly? > That would be one click only. In bug 792905, the bug reporter said (which I think is your answer): > Reset range only resets the color balance to the already "remembered" color balance. So that's a bug, I think. But this doesn't totally remove the discussion altogether, which is probably still valid (but I don't really have the answer).
(In reply to Michael Natterer from comment #5) > Also, you say you have to click at least 5 times, is the global > reset button at the bottom of the dialog not working properly? > That would be one click only. Ah, my bad - I never saw the global Reset button at the bottom of the Levels dialog - I can be incredibly unobservant of stuff that ought to be obvious. The original bug report was about being able to use ctrl-f to apply the last-used operation again, yes? I wasn't aware of this keyboard shortcut, which seems very useful in cases where someone wants to make the exact same adjustment to a bunch of different layers. Which is something that personally I just don't do. But I can imagine that in some workflows, for some purposes, this might be very convenient. Does the option to use ctrl-f absolutely depends on having the last-used parameters be automatically loaded when accessing items on the Colors menu? This new behavior - well, it's the "same old" behavior for some of the tools on the Colors menu such as Hue-Chroma and Exposure - makes editing more difficult. The problem is two-fold: First, it's "one additional click" every time any item on the Colors menu is used, just to get back to "no change". How many times in a row and in what sort of workflow does someone actually want to make the exact same Exposure change over and over again? And so on for all the other items on the Colors menu. Second, usually (well at least for photography and painting, at least in my own workflow), color and tonality changes are made "by eye", "a little more of this, a little less of that", and the usual intended *visual* starting point is "no change". Having a more or less radical change in colors and tonality be automatically loaded every time someone wants to use an item on the Colors menu is a disruption from the colors and tonality that the user was actually intending to change. So after hitting "Reset" to get back to the original colors, there necessarily is a brief moment to reaccomodate the eyes to settle again on what the desired change was. This may sound stupid, but it's actually a matter of how very quickly our eyes adapt to changes in colors and tonality. For example, consider an intention to use the Hue-Chroma tool make a particular color of blue "just a little more on the green side of blue", and let's say the automatically loaded "last used" settings actually changes the original blue color to a brighter, higher chroma magenta. Hitting "Reset" of course gets the color back to "no change". But then the eyes also have to "reset" because of how quickly our eyes accomodate ("adapt") to changes in colors and tonality: looking at bright high chroma magenta and then switching back to the original blue automatically makes the original blue look more green, slightly darker, and less saturated than it really is. Of course this "adapted" perception of the original colors that the user actually wanted to modify only lasts for a couple of seconds. But it's annoying and disruptive to have one's editing software keep flashing more or less radically altered colors instead of presenting the "unchanged" colors that the user actually wants to modify.
(In reply to Jehan from comment #6) > In bug 792905, the bug reporter said (which I think is your answer): > > > Reset range only resets the color balance to the already "remembered" color balance. > > So that's a bug, I think. > But this doesn't totally remove the discussion altogether, which is probably > still valid (but I don't really have the answer). Yes that's written there but I don't see that happening. The reset button works just fine.
The unrelated issue of *defaulting* (not remembering) to the last used settings was just fixed in bug 794826. So if I see things correctly, the items in "Auto" are the only things remaining to be fixed.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/1284.