> 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
--
・‥…━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━…‥・
timecop at japan.co.jp | ＯＡ通信サビース株式会社 | NTT DoCoMo
I thought everything that Linus Torvalds is involved with was divine
perfection? Must be a problem with NEC and Sony -about Crusoe recall
・‥…━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━…‥・
