This one covers a lot of things I previous mentioned in a bit better tone.
Quoting comes from Raphael Quinet's post #12115.
Wow, finally a person who understands my concerns, and is actually an
active gimp developer, so that things could really change :)
> Although I don't like timecop's style and arrogance (timecop, please
> change your style if you expect more constructive replies), I think
I have been trying. Unfortunately after my initial tone was severely
misinterpreted, it's difficult to get anywere, heh.
> that he has a good point. The example with Alt-F + X may not be the
> best, but the idea of allowing all menu entries to be reached by a
> sequence of keys is good (not that I would implement it, but still...)
There shouldn't really be a question of implementation - the GUI toolkit
should probably take care of this much better than anything else. The
only issue I can see here is from focus switching between image/toolbox,
but that can probably be taken care of, too. Especially things like handling
key presses once the menu is open should absolutely not be handled by the
application. Take a look at how standard menus operate on Windows/Mac
whatever, and come up with a consistent solution to use in GTK. One thing
that is already overlooked at this point, is things like handling multiple
accelerator keys on the same menu - it should cycle through available choices
instead of doing what it's doing now - firing off the first available choice.
In the situation where cycling is enabled, user needs to press enter after
the selector is positioned on the correct menu. This is a worst-case
scenario - in a properly thought-out application, these conflicts should be
minimized. The only place where this kind of issue could come up is on the
filters menu where (well placed) stock plugin underline conflicts with some
outside user-installed plugin.
Again, take a look at the "other" toolkits doing it - specifically QT and
Windows.
One thing that should probably be disallowed, and might make a number of
people upset, is assigning "dynamic shortcuts" combinations to just single
letters. Therefore, either a new method for assigning toolbox shortcuts
needs to be created, or those need to be static, and not configurable. I
think, dynamic shortcuts should be limited to Ctrl+xxx and Ctrl+Shift+xxx
only, for two reasons, all keyboards are guaranteed to have those keys,
Shift-xxx and single-letter combos should be reserved for tool and state
changes, and alt for menus or things like that, and the other reason is
the conflict issue, if you let users change dynamic shortcuts to include
alt and shift and single letters you could possibly end up with a mess.
> I do not think that I am totally nuts, and I do use the Gimp from time
> to time on a laptop that has a small screen and a crappy trackpoint.
> Of course I only use it for simple things (mainly web-quality images,
> not high-res photos), but it works reasonably well. I do the more
> serious editing on my PC at home when I want a better quality, but the
> laptop is sufficient for quick and dirty work. And indeed, I have
> wished several times that I could use the keyboard to access some of
> the plug-ins. And I do not know any better solution than the one that
> timecop is proposing, because the current way to assign shortcuts to
> menu entries is limited by the total number of keys that are available
> (multiplied by the number of modifiers) and it would be impossible to
> remember all of these unique combinations anyway.
And it's actually quicker to right click and use keyboard on a laptop since
the mouse buttons are usually really close to the keyboard. Certainly faster
than remembering some obscure combination like Ctrl+Shift+J because it really
doesn't mean anything to the user since it's bound to "16x zoom" menu
item, unless you associate "Jumbo" with 16x zoom, or something like
that. This is a off-the wall example, I don't think Ctrl+Shift+J is
actually bound to anything by default. Again, once someone takes all the
modifier shortcut keys and arranges them in a sane order, this should not
really be an issue, either.
The right click might not apply to me because on my laptop I bind the second
button to Button3, and both left and right to Button2 if nothing else but to
improve cut & paste behaviour which requires pasting with the 3rd button. I
figured I use the right click not-so-often that when I do need to use it I
can deal with pressing 2 keys at once.
> This is something that should have been mentioned earlier, and it is a
> pity that timecop sent his inflamatory mail instead of calming down
> and trying to find the root causes of the problems that he described.
Yah. Many people told me that already.
> The shortcuts in the Gimp lack some consistency in the way they use
> the modifiers. Alt and Ctrl are used everywhere in the menus and the
> combinations of letters and modifiers were more or less chosen on a
> first come, first serve basis (plus some influence from other programs).
> Some other programs stick to the (MS?) guideline: use Alt for opening
> the menus, and Ctrl or Ctrl-Shift for invoking some action directly
> without opening the menus.
True. While Alt-F might be easy to push because the keys are close together,
it is not very intuitive. Ctrl+R is already taken by a very standard "redo",
so another sequence will need to be implemented for "Repeating last filter".
Ctrl+F seems to be open, at least on my installation, but I am sure there are
better solutions to this problem - one could even go as far as adding a
"track usage" feature to the gimp menu system, and give user the option to
submit these reports to gimp developers, where usage patterns are analyzed
and most commonly used menus would have sane shortcuts assigned to
them. I guess without a expensive usability lab one of the posters talks
about, this is probably the only way to get a "unbiased" look at most
often used commands. Again, something tigert uses might not qualify as a
good shortcut set because he's a professional. :)
On the side note, while dynamic shortcut reassignment is good, it also could
theoretically impair learning by new users, because they would expect the same
shortcuts they are used to using, and for example in a lab installation where
each machine runs Gimp, every user is free to change the shortcuts as they
seem fit. Therefore after trying a few times and finding out that the
"standard" shortcut doesn't work, user gives up and reverts to using the mouse.
In this case, fairly "standard" things like underlined items would be much
more useful - <Image>->Filters->Map->Displace is always under
Alt-R-M-D, at least in English version of Gimp. Not too many people do
locale hopping enough to invalidate this for translating underlines into
native language - for foreign users it would be much more intuitive to expect
menu underlines to be from familiar words in their native language. Those that
switch between say English and German locales either have to deal with it, or
come up with a more elegant solution :)
> Using the Alt key for opening the menus (toolbox menu or image menu)
> would mean that the (very useful) Alt-F shortcut would have to go. It
> would have to be re-assigned to some Ctrl-key combination. A lot of
> other shortcuts would have to be replaced, but in the end I think that
> the final result could actually be easier to use for everybody.
The goal of something like this would be consistency and intuitiveness.
As the author points out, current 2-3 key shortcut state is not very organized.
And also another point I will probably get flamed at is that there is really
no reason to have -too many- of these kind of shortcuts. They should exist
for standard operations that everyone uses - Open, Save, Exit, and they should
absolutely use the most common denominator key combinations one would expect
to see - which means a number of Windows/Macintosh/Whatever software packages
would have to be analyzed, probably to come up with that Open should be at
Ctrl+O, save at Ctrl+S, etc. Then one would have to think about the next
level of most commonly used shortcuts - image operation, palette operation,
invoking important dialogs, etc. For example, "Toggle Statusbar" shortcut is
really questionable - it provides no real "use" except hiding important
information from the user. But Layers and Paths dialog is very important, so
the current Ctrl+L key should definitely stay. On the side note, why isn't
Layers and Channels entry list the Ctrl+L shortcut next to it? On my install
it's empty. Also, I think most of the items in the toolbox should be
selectable by either a single letter or shift-letter combination. Because
these actions don't actually do anything but change the current mode state.
Reserve things like Ctrl+xxx for common items such as dialogs, often used
commands, and the like, and Ctrl+Shift+xxx for more obscure things that are
used less often, like toggling guides, or grid snap. Like the author says,
things like Alt-xxx could be theoretically reserved for opening menus.
> Please do think about it for a minute instead of throwing the idea
> away because of timecop's arrogance. I tried to think about the pros
> and cons, and I think that a more consistent way of assigning the
> shortcuts could help in the long run.
> Anyway, this is a major change that should definitely not go into 1.2,
> but maybe it should be considered for 1.3/1.4.
> I don't think that his idea of requiring a right-click in the image
> for opening the context menu and _then_ using the keyboard is a good
> idea. Instead, I would prefer that Alt-F opens <Image>->File
> directly, and so on for the other entries in the context menu. If your
> pointer is over the toolbox and not over an image, then it would open
> the File menu in the toolbox.
Actually that makes a lot of sense - and I haven't thought of that. That if
the mouse focus is over the image, alt-xxx would handle <image> menu, and
otherwise, the little File/Xtns/Help combination on the main toolbox.
> Right. I have two new keyboards in my office. One is attached to a
> Sun workstation, the other one to a PC. None of them has a Windows
> key. A colleague of mine has a keyboard with this key, but it is used
> by his window manager. Since the key is grabbed by the WM, the Gimp
> does not even see it when you press it.
It could be configurable, like I mentioned in one of my posts, and if user
chooses to assign that key to the Window Manager, then so be it. As someone
mentioned, the "Menu" key would be more intuitive to use for this rather than
the "Windows" key - and it would integrate beautifully with the Win32 port
of Gimp. Heh.
> I disagree with the statement that it is easier to use the cursor keys
> to navigate through the menus. Having additional shortcuts does not
> prevent you from using the cursor keys, but once you have learned some
> key sequences such as Alt-A B C, it is easier and faster to use that
> than most other methods (navigating with the mouse or the cursor
> keys). The single-key shortcuts are faster, but you cannot have too
> many of them. The advantage of using key sequences is that they can
> be easier to remember because the mental effort is not much greater
> than the effort needed for remembering a path through the menus (like
> the fact that Displace is under <Image>->Filters->Map->Displace), and
> this information can be refreshed easily.
Right, exactly my point I have been trying to make, just didn't know how to
explain it better. :)
Anyway, I hope people who have previously just yelled at me about this kind of
thing would re-read this again and try to understand the concerns here. While
I do agree that none of this will probably make it into 1.2, but I would be
very happy to see such improvements in 1.3+, and if I ever figure out where to
start, I could even contribute something on this other than just "words".
This leaves us with another issue, keyboard shortcuts on all dialog boxes, but
that's a whole another story... :)
One suggestion though - have things like dialog border width, and item spacing,
etc as constants - GIMP_DLG_BORDER_WIDTH, GIMP_DLG_SPACING, etc so that each
plugin author creates consistent looking interfaces, instead of the current
state where everyone just guesses values for these kind of things and the end
result is not usually pretty.
tc
--
timecop at japan.co.jp | ＯＡ通信サビース株式会社 | NTT DoCoMo
