> So what happens when the four plug-ins in a dynamically generated > sub-menu are called: > _C_ool splash effect > _C_ool burn-through > _O_rangify > _C_lout You shouldn't even have to worry about issues like this. Naturally, repeately pressing the "C" key would toggle through the list of available items that have "C" as the shortcut. Doesn't GTK already automatically provide for this? The only difference in this case, instead of instantly invoking the menu, only focus would be moved, and there you would have to press "Enter" to accept the menu. Again, that's common sense operation the user would expect from the menu. And since plugins provide a suggested location inside the gimp_install_procedure, you can always attempt (at least for stock plugins) that a separate, meaningful letter is used for each. One could analyze a string such as "Selective Gaussian Blur" in the context of other "blur" entries, and have something like: _B_lur Gaussian Blur (_I_IR) Gaussian Blur (_R_LE) _M_otion Blur _P_ixelize _S_elective Gaussian Blur _T_ileable Blur See, that wasn't so difficult, and we still have 19 letters of the alphabet left to assign around that particular menu. But now instead of doing a lot of little mouse motion, I can right click, and type "F-B-S" and I am at the Selective Gaussian Blur dialog. Pretty slick, considering the time to press those 3 keys is definitely less than moving the mouse and clicking the appropriate menus. Not to mention that if you make a mistake you gotta right click again and start over. I am not saying anyone should force new plugin developers to control how external plugins define these shortcuts, but as long as the core plugins follow a sane and intuitive naming, then there is no problem. And like I said above, even if there are conflicts, all it does is allow to cycle through the available "conflicting" choices, but instead of activating the first one, would require pressing "enter" on a particular focused menu. And if a plugin doesn't provide an underline entry, one could be automatically generated after eliminating all existing entries already assigned, then following First Letter Underlined, and if that isn't possible, to some other one etc. > Hmm? That is the problem you must solve if you want there to be a useful > underlined symbol in each entry in each menu in Gimp. You must also > solve it for the multi-lingual and other cases, but just the "easy" case > should be enough for now. I provided examples of the international use in my previous post. To reiterate it here, you either a) translate the underline, making sure it is still meaningful in the native language, or b) handle it the way asian software handles it, and that is adding a shortcut in parenthesis after the menu item name: "J(_O_)... Ctl+O" translation "Open(_O_)... Ctl+O" "I(_X_) Ctl+Q" translation "Exit(_X_) Ctl+Q" Gimp's ja.po already uses this scheme for the top-level menus in the gimp toolbox window. It should be kept to [ja|ko|zh].po though, because that's how they are used to using it. Latin-1 languages should use normal underlines inside the menu item name. Languages such as Russian or those with extensive alphabet entries below first 128 characters of the ASCII set should be handled no different than Latin-1 - that is menu entries translated, and an intuitive letter of the native alphabet underlined. Does GTK handle high-bit-set accelerator keys? It should, if it's going to be a useful GUI toolkit. These are guidelines most sane software follows which is written for that other desktop operating system. I may not necessarily agree with translating underlined shortcuts into a native language because it would confuse someone who deals with English version and gets used to the english ones, as I had to do (see previous posts), but I think number of these kind of people is less than one would have to worry about. And that's my personal opinion so it could be easily ignored. Hopefully this clears out some of the menu issues. > A Window key - mapped to Super/ Hyper, and used for... Windows. Most > people who care are using these to control their... Window Manager. A > properly thought out way of using a GUI. Gimp already uses too many > controls that are likely to be mapped away and then "mysteriously" not > work. Any way the right key would be the Menu key, not the Window one, > and mine is mapped to (duh) the system Menu. Hey, that's -YOUR- window key. Throughout this thread I felt like I was always being talked down because these are -MY- ideas. Nobody wants to hear them because they are -PERSONAL- and -YOU- don't -LIKE- them. Instead, why not make things like that configurable? That preferences dialog needs to be unkludged, and how about seeing an option like: "[x] Grab Win95 keys for Gimp" "Use [ Windows ] key to invoke the root menu" [ Menu ] Naturally, clearning the "Grab" checkbox would disable the selection below, so those of you who assign the "Menu" key to your window manager, are still happy. What do you think? The whole preferences thing could have a new subtree entitled "Keyboard control" where one would choose things like the above Win95 key assignment, enabling/disabling of underline accelerators, etc. Then instead of complaining about -MY- bad preferences, you just disable them, and use your mouse. tc -- $B!&!E!D(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,!D!E!&(B timecop at japan.co.jp | $B#O#ADL?.%5%S!<%93t<02q

Reply via email to