GNOME Bugzilla – Bug 84640
Clicking the Auto Button in the levels tool is weird
Last modified: 2005-07-26 14:48:27 UTC
When you click at the Auto Button in the Levels tool, the image gets adjusted, but the arrows in the upper part of the dialog do not reflect the new situation. Also it is impossible to reset the effect by clicking on the "Standards" Button.
Ok, this is not a bug, but an issue with an weird GUI. "Reset" only resets the current channel (despite its position that makes it look like it would affect all) and "Auto" changes the Red/Green/Blue Channel. In an Discussion on IRC we thought about adding more buttons to the GUI with "Reset", "Reset all", "Auto", "Auto all". Probably it is a good idea too to make it more obvious to the user that there are four channels he can fiddle with. Maybe a Tabbed Dialog would be useful for this.
Created attachment 9728 [details] Mockup of proposed interface, see other notes for extra info
The above PNG is a mockup made with Glade and GIMP. Probaly not a good idea for 1.2, but maybe fine for 1.3 (I set the OK Cancel as in 1.3). Notes: - Auto Value becomes Auto Red, Auto Green and Auto Blue in the other tabs. The same with Reset Value. They say Value, not Values, can be confusing the first time, but it makes lot of sense as soon as you look any other tab. In case of working with CMYK, extrapolate. Required retouches: - Consistent paddings in general. Maybe make nicer the All Channels and Settings buttons, they look a bit too big horizontaly. - OK button have the default, so enter activates it, start with focus in spinbuttons and allow changing around the five with kbd. - Output levels spinbuttons should look more like current, with padding in the end. Or maybe padding in the middle and make it copy the Input row, but without the middle spinbutton, just a blank there.
As long as we're discussing usability of this dialog, can I mention another thing that always confuses me about it? In the three-sliders section when showing Value, just above the sliders is a gradient from black to white. If I take the slider from the dark end, and move it toward the light end, I expect the dark parts of the image to get lighter. But instead, the light parts of the image get darker (and vice versa for the opposite slider). I mentioned this on IRC, and a new way to think about it: that the histogram inside the new slider positions is going to be mapped to the whole Value range, so in other words, if I drag the black slider towards lighter colors, those lighter colors after the remapping will become dark, hence the resultant image is darker. This seems obvious now that it's explained to me, but for some reason it wasn't obvious without the explanation. It's made more difficult by the fact that the other slider in the dialog (Output levels) works the opposite way: dragging the dark slider toward light makes the image lighter. I don't have a better UI to propose to solve this problem, though; I thought about separating the two gradients and drawing a wedge or a pair of lines/curves from the outside edges of one gradient to the slider positions on the other, but I tried a mockup and it looks stupid as well as taking up too much vertical space.
I have a patch that does all but the tabs (it uses a frame instead, with the current selector). It looked like tabs meant using GtkNotebook and creating four duplicates of everything inside the tabs, so I stopped hoping that someone more familiar with gtk knows a better way.
Created attachment 9818 [details] [review] Implement everything but the tabs
I'm not too satisfied with the proposed UI design but I've set the target milestone to 1.3.x so we definitely consider to apply the patch.
Added a separate Button while refactoring the color correction tools. Unfortunately this obsoletes Akkana's patch since lots of code has been changed and rearranged... 2002-08-26 Michael Natterer <mitch@gimp.org> (...) * app/tools/gimpcurvestool.c * app/tools/gimplevelstool.c: added separate "Reset Channel" buttons and let the global "Reset" buttons reset all color channels.
Removing the PATCH keyword since there's no useable patch attached to this report.
Bumping a bunch of enhancement requests which will not be done by the feature freeze to Future. Dave.
Actually, as I just added to bug #141930, this is not a bug. At least not after we changed the Reset button. That basically fixed it.
I don't think it makes sense to keep this report open any longer.