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 | OA通信サビース株式会社 | NTT DoCoMo

Reply via email to