On Thu, 14 Dec 2000, <timecop@xxxxxxxxxxx> wrote: > 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 :) Calling me an "active gimp developer" is a bit too optimistic.... I wish I had more time to fix the bugs that I have detected and to write the code for the cool features that I am dreaming about. But I am still waiting for Santa to give me more than 24 hours in a day. As a result, it can take a long time for me to write some code or to submit patches that I have already written but not thoroughly debugged, as you can see here: http://advogato.org/person/neo/ (Hi Sven! ;-) And the recent mention of the "Alpha to Logo" scripts in another mail reminded me that I have to do something about the missing ones... > > 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. It should not be hard to understand why your initial tone was "severely misinterpreted". Read it from the point of view of a developer who has worked hard to bring the gimp where it is today and who does not see any smileys or hints of humor (or modesty) in your message. The initial impression is often hard to correct. Ah well, let's all be a bit more tolerant. And let's hug and dance around Barney... :-) > > 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 Yes, this is definitely something that should be done at the GTK level. Alas, GTK has not been designed with enough attention on the keyboard support. This reduces the usability and accessibility of many applications (GNOME). Each application should be able to customize the shortcuts as necessary ("let the users/developers choose"), but GTK should at least provide better defaults. If an application does not create its own shortcuts, GTK should assign them automatically to all menu entries. For example, unless told otherwise, GTK could automatically underline the first non-conflicting letter of all menu entries that do not have a shortcut. > 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. Yes. I have to admit that Qt has a better design when it comes to the accessibility issues (it has other drawbacks, though). And Windows too. The difference is obvious if you disconnect the mouse from your computer and you try to do anything complex involving several applications under GNOME, KDE and Windows. In many GTK applications, you are stuck as some point and your only hope is that you window manager has some Alt-arrow key combinations for moving the pointer around or some key for closing the offending window. It is also important to keep in mind that the keyboard support is not only an issue for those who have no mouse (a minority, even among those with disabilities) but also for those who do have a mouse but want to navigate the menus faster using the keyboard. > 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. Yes, you could end up with a mess. But no, this should not be disallowed by GTK. A tool like the gimp (and GTK) should give you the ability to shoot yourself in the foot if you really want to. However, it should at least ask you for confirmation. >From the toolkit's point of view (GTK), only the Alt-key combinations could be special because they would be assigned to the menus. But all other shortcuts (Ctrl-xxx, Ctrl-Shift-xxx, Shift-xxx, xxx) should be allowed because the conflicts can easily be solved by the context: - if you are in the "application" context, all keys go to the application (invoking whatever action has been defined), - if you are in the "menu" context (i.e. you have used some Alt-xxx combo to open a menu), then all single-letter combos are used for selecting entries in the menu. [...] > > 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. :) Well, I had a quick look at my ~/.gimp-1.1/menurc and here is a totally unscientific overview of the Ctrl-xxx and Alt-xxx combinations that I use the most often (roughly in that order): Ctrl-Z (Undo) Ctrl-R (Redo) Ctrl-H (Anchor Layer) Ctrl-M (Merge Visible Layers) Ctrl-L (Show/raise the L&C&P dialog) Ctrl-W (Close Window) Ctrl-Q (Quit) Ctrl-K (Clear) Ctrl-V (Paste) Ctrl-C (Copy) Shift-Alt-F (Re-show last filter) Alt-F (Repeat last filter) Ctrl-X (Cut) Shift-Ctrl-A (Select none) Ctrl-I (Invert selection) Ctrl-A (Select all) Shift-Ctrl-O (Offset) Ctrl-D (Duplicate Image) Ctrl-S (Save) Ctrl-T (Toggle selection) Shift-Ctrl-M (Merge down) Ctrl-N (New image) Ctrl-O (Open file) Of course, this is only my point of view and I am sure that other people use many more shortcuts than that. However, I noticed that the only Alt combo that I use frequently is Alt-F/Shift-Alt-F. It should not be a problem to remap this to Ctrl-F/Shift-Ctrl-F. The latter would conflict with Select/Feather, but that could be changed to Shift-Ctrl-E which is not used yet (Ctrl-F is also used to raise a layer or a channel, but only in the context of the L&C&P dialog). As a matter of fact, the default menurc contains only five Alt-key combos: Alt-F, Shift-Alt-F, Alt-G, Alt-I, Alt-R. The last three are used for changing the image to grayscale, indexed or RGB mode, but I do not think that they are used so frequently, therefore they could easily be replaced by the key sequences Alt-I-M-G, Alt-I-M-I and Alt-I-M-R. So it looks like the benefits of using the Alt key for the menus would far outweight any disadvantages of having to learn some new shortcuts, because the majority of people who use the default menurc would only have to care about the change in Alt-F and Shift-Alt-F. Is anybody using some other Alt-key combos so frequently that it would be a problem to reassign these to some Ctrl-key shortcuts? It looks like this "major change" is not so big after all... [...] > 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 :) One possible solution would be to have an option in the Gimp preferences that says something like: "use english menu shortcuts instead of localized shortcuts". It would be unchecked by default, but anybody who has to switch frequently between different versions could check it and have a uniform set of shortcuts. This would involve some tricks in the translation of the menus (i.e. tell GTK to use the original key for the shortcut even if that letter does not appear in the translated string), but we are already doing some ugly stuff for translating the menus so it cannot be much worse. The translators would simply design the shortcuts for their language, and the Gimp could override these if the user prefers the original ones. > > 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. I just thought about something that could be even better: if the current input focus is on the image, the L&C&P dialog or the toolbox, then using Alt-xxx would open the corresponding menu for that window. In addition to that, we could use Shift-Alt-F, Shift-Alt-X and Shift-Alt-H for going directly to the toolbox menus even if the focus is currently on another window. That would provide a convenient access to the <Toolbox>/Xtns menu whithout having to move the mouse. > > 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. Hey, I don't have any Menu key either! :-) Seriously, I think that the default set of shortcuts should only rely on Ctrl, Alt and Shift, which are more or less universal (except on the Mac, but then we can use the Apple and Command keys). We can also provide additional shortcuts using the Menu key or Windows key, but we should not rely too much on them. > > [...] 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". As explained above, this would actually require very few changes in the Gimp. There are only five shortcuts that would have to be changed (six if you also change Select/Feather to Shift-Ctrl-E), so the only reason for not doing this in 1.2 is that a lot of books and tutorials are refering to Alt-F and Shift-Alt-F for repeating the last filter. Changing this for Gimp-1.3 and future versions would be very easy. However, the clever stuff will have to be done in GTK. It would be very nice if the Alt menu shortcuts could be enabled by default in GTK 1.3.x (and 1.4). I hope that it is not too late to add this accessibility feature in the current GTK development branch. > 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. Good idea. But other things like the ordering of the buttons cannot be easily defined by constants. Hmmm... That would at least be a step in the right direction... -Raphael P.S.: I tried to keep this message short, I swear! ;-)
