After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 425258 - Shortcut for Channel selection in Curves dialog etc.
Shortcut for Channel selection in Curves dialog etc.
Status: RESOLVED OBSOLETE
Product: GIMP
Classification: Other
Component: User Interface
2.2.x
Other All
: Normal enhancement
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on: 436480
Blocks:
 
 
Reported: 2007-04-01 19:11 UTC by erik_m85
Modified: 2018-05-24 12:10 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description erik_m85 2007-04-01 19:11:49 UTC
I can't find a way to set up a shortcut that will let me switch quickly between editing curves for the different channels (R,G,B,Value,Alpha) in the "Curves" and "Levels" dialogs (perhaps there are more similar dialogs).

When tweaking curves, I find it helpful to often switch between the channels to make small incremental changes while previewing the effects. This becomes a struggle when I have to go trough the drop-down menu/combo-box. Also, I would be nice if I did not have to move the mouse, since I might want to place a point in the "same place" in the curve-area for a different channel.

I have looked in the Preferences > Interface > Configure Keyboard Shortcuts dialog without finding a way to set up such shortcuts.

I'd like there to be "hooks" for these shortcuts. I only need them within the mentioned dialogs (Curves, Levels) - and if they are made "local" then collisions would be avoided and I could use some simple keys like V,R,G,B,A or digits (like I think Photoshop has) altough these keys may have different meanings outside the mentined dialogs.
If this can be accomplished then I'd suggest to use V,R,G,B,A as defaults on RGB-images (first letter of the english channel names). Guess it becomes complicated because of CMYK, Grayscale and perhaps numbers 1,2,3... are the best way and their meanings would be just the corresponding channel from the list of whatever channels there are (in the mentioned dialogs).
Comment 1 Sven Neumann 2007-04-11 10:11:46 UTC
How could this be made discoverable? I don't think it makes sense to add hidden shortcuts so there needs to be a way for the user to find out that such shortcuts exist.
Comment 2 erik_m85 2007-04-16 18:55:32 UTC
That's certainly true.
Are tool-tips possible for individual items in a drop-down list? Probably not :(
If Alt-shortcuts would be used then underlining one (unique) letter for each word and using it together with the Alt-key would be common practice.
If any other combination is used, perhaps it can be printed right-aligned in the list as in menus. The list box would need to be a bit wider then, but it would fit without more changes than moving the "Reset channel"-button a bit to the right.
Comment 3 Sven Neumann 2007-04-17 06:46:48 UTC
If that's the way it should be implemented, we would have to open a bug-report against GTK+ and ask for mnemonics to be added to GtkComboBox. But somehow I doubt that this would be a successful request.
Comment 4 peter sikking 2007-04-17 12:27:01 UTC
do not go for alt-keys. makes for awkward chord-ing with the non-mouse hand.

ease of use (efficiency) has a much higher priority then ease of learning, at GIMP.
so put in the R, G, B, A, V shortcuts to begin with.

Now the ease of learning part:

Those two dialogs are loaded, no room for a little tip.

What is a very simple solution is to label the items in the pop-up list like this:

Value (V)
Red (R)
Green (G)
Blue (B)
Alpha (A)

If we could get the (X) part with less contrast (e.g. gray, instead of black) that would be good.

Then internationalisation. There I would like to ask: how it is solved at the moment in the GIMP color selector? I mean those HSVRGB buttons.
Comment 5 Sven Neumann 2007-04-17 18:52:36 UTC
What Peter suggest is not really a standard and established user interface. I doubt that users will understand the meaning of these labels. And no, we can't reduce the constrast. The fact that the labels are black on Peter's computer is just because his theme uses black as the foreground color. On someone else's computer these labels might be bright orange.

The button labels in the color selector are marked for translations.
Comment 6 peter sikking 2007-04-17 22:05:12 UTC
what I suggested is not really a standard and established user interface, because what we are trying to achieve is ot really a standard and established user interface. But is comes with the calibre of GIMP: relentless efficiency.

As long as we create really hot ways for our core users to work, it will be fine with me to bend the guidelines a bit. It is really a no-brainer for me that the  alt-key should not be involved in all this. So much more sensible, as long as the two dialogs are modal.

I could actually live with the fact that users find out about the R, G, B, A, V shortcuts via osmosis, discussions on the internet, books about GIMP and the tip-of-the-day dialog.

If you want to show a hint, then you can do what I say above, or squeeze in a hint text in those already disturbingly busy dialogs, or replace the pop-up menu with something else (radio buttons; buttons from the color selector) in those already disturbingly busy dialogs.

I tried to show above that I do know that the text in the pop-up is theme dependant, the black was an example (e.g.).

About the button labels in the color selector. What tokens can I grep for on my disk, to see what is HSV/RGB called around the world?

to be continued
Comment 7 Sven Neumann 2007-04-17 22:21:25 UTC
We use the Alt keys all over the place in our user interface, just like all other applications out there use mnemonics. I don't see why this should suddenly be akward. But this doesn't belong here anyway. If this needs discussion, then it should be discussed on the mailing-list.
Comment 8 peter sikking 2007-04-17 23:30:24 UTC
let's keep the horse in front of the cart.

We try to invent something new her (shortcut key for a pop-up menu), no rules written we must use mnemonics, we have the opportunity to use the 'naked' keyboard keys (like ooooooh, the toolbox,
I did not invent that, but I can see the comfort and efficiency) because we are modal and there is nowhere to type alphabetic characters in the two dialogs.

Look at it in that order and really optimising this case, and I do not see the alt key helping the user in any way. Do not confuse this with the standard and prescribed situations where mnemonic have to be used. 

We are not breaking the rules, we are working in an area that the guidelines do not cover. Luckily I am fully comfortable working in these situations, just focus on the product vision and do the right thing.

I focus on Erik (and 10000 other users) working bang-bang-bang on the RGB levels/curves.

Then the solution seems obvious to me.

Now that I stare some more at the curves dialog: this may work well enough: similar to the Save button in the same dialog trying to squeeze in a shortcut (shift) in the tooltip, we could do the same hovering over the *closed* channel pop-up. When the green channel is the current channel the tooltip would be "Adjust green channel curve  G" Trivial tooltip, but it connects the letter G with the mode.
Comment 9 erik_m85 2007-05-07 00:40:01 UTC
(In reply to comment #3)
> If that's the way it should be implemented, we would have to open a bug-report
> against GTK+ and ask for mnemonics to be added to GtkComboBox. But somehow I
> doubt that this would be a successful request.

Regardless of how this discussion might end, I created http://bugzilla.gnome.org/show_bug.cgi?id=436480 to be able to present at least the standardized kinds of shortcuts in a GTK combo box.
See also http://bugzilla.gnome.org/show_bug.cgi?id=303717 about tooltips, wich might be more useful here, since a non-standard method might be most suitable and a tool tip will give room for its explanation.

I'd personally prefer plain keys without Alt or Ctrl, but anything is better than no shortcuts at all.

I also think the case of CMYK, HSV, Graysacle, custom(?) color modes need consideration. Are all possible names for color channels known at compile & translation-time? If not then you can't even know that first letters will be different and thus have to select shortcut letters in a more complicated way, at run-time. In that case then using numbers 1,2,3,... might be simpler to implement, and at least work for 9 channels (which I've never seen used anyway, so it should be enough).
Making these shortcuts customizable, as regular shortcuts, would perhaps be overkill, and prevent them to be identical to other shortcuts outside of the dialog (using the modal nature of the dialog).
Comment 10 GNOME Infrastructure Team 2018-05-24 12:10:41 UTC
-- 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/239.