[haiku-bugs] Re: [Haiku] #7967: Update menu modifier images to more accurately reflect the corresponding key that appears on the keyboard
- From: "jscipione" <trac@xxxxxxxxxxxx>
- Date: Wed, 09 Nov 2011 19:02:24 -0000
#7967: Update menu modifier images to more accurately reflect the corresponding
key that appears on the keyboard
------------------------------+----------------------------
Reporter: jscipione | Owner: stippi
Type: enhancement | Status: new
Priority: normal | Milestone: R1
Component: User Interface | Version: R1/Development
Resolution: | Keywords:
Blocked By: | Blocking:
Has a Patch: 0 | Platform: All
------------------------------+----------------------------
Comment (by jscipione):
Replying to [comment:20 tangobravo]:
> Another problem is what about other mentions of these keys - eg in the
HTML documentation or forum posts etc?
I don't think it is as big a deal as you think it is. And this is a
problem already. In fact making the menu bitmaps static only worsens the
problem.
> Although I share your frustration that key roles add an indirection that
harms usability, there isn't really an alternative when we are an
alternative OS that wants to support both Mac/PC hardware.
Allow me to disagree. My above proposed solution is exactly that, more or
less.
> Right now I'm typing this on OS X on a new MacBook Pro, but using a
Microsoft UK PC keyboard plugged in by USB. It annoys me that I can't set
independent keymaps for the two keyboards (so the @ is in the right place
on the USB one but no longer where it is shown on the mac keyboard); but
there is simply no way for the OS to give me a modifier bitmap
corresponding to the key I should press for a shortcut, as the same key is
marked differently on the two keyboards.
I agree that is annoying but that is a different problem. In order to
solve that we'd have to change keymaps to work per keyboard. Also, you are
going to probably want to have multiple keymaps per keyboard as well. It
is certainly a problem that could be solved, but, again, it is a different
problem then the one described in this ticket. File a bug report about it.
>
> We should of course optimise for the common case, which may well be the
bitmaps you suggest for the standard PC keyboard mapping. My main concern
is then which convention should be followed for static documentation - key
roles would suddenly not be exposed at all top those with the "common
case" setup so would cause confusion, but using the WinPC bitmaps directly
would be plain wrong for the significant minority with different setups.
The 3 modes I outlined above represent the 3 most common cases in
descending order. PC, PC w/Control and Command flipped, Mac.
Replying to [comment:21 bonefish]:
> Now I'm utterly confused. I thought you agree with the key roles
approach. But that would imply labeling the keys on the keyboard in Keymap
with "CTRL", "OPT", "CMD" and also use respective shortcut bitmaps.
We are in agreement that key roles are the best approach, meaning that the
bitmap that appears in the menu would not rely on the keymap.
> Er, maybe people have different visions of how a key roles based
approach would work. To clarify, mine (which I find simple and stringent)
would ...
> 1. switch the legends on the keyboard in Keymap when switching between
Mac/Haiku and Windows mode as done already (r43228),
You must have meant a different commit because r43228 has nothing to do
with this.
> 1. not switch the shortcut bitmaps *ever*.
If you are willing to live with the fact that on a PC keyboard the Windows
key corresponds to a menu bitmap that says "OPT" and the Alt key
corresponds to a menu that reads "CMD" and you are willing to live with
the fact that when you switch the control and command keys via the "Switch
shortcuts to Windows/Linux mode" button in Keymap the Control key
corresponds to a bitmap that says "CMD" and the Alt key corresponds to a
menu item that reads "CTRL" and are willing to live with the fact that on
a Mac keyboard the Option key corresponds to a bitmap that says "CMD" and
the Command key corresponds to a menu bitmap that reads "OPT" then ok.
I find all that terribly confusing though and I think that the input
server could take care of all of it for you without you having to do
anything.
> Particularly the last point is why they are key roles. CMD is the main
shortcut key role. Always. Keymap would visualize the mapping of physical
keys to key roles. That might be considered confusing, since the key
physically labeled CTRL wouldn't be mapped to the CTRL key role in Windows
shortcut mode, but as we already established keyboards with localized
legends don't quite match anyway. The "ideal" solution would be to invent
names for the key roles that don't clash with actual key labels, but given
the obscure kinds of key labels that do already exist (Meta, Super, ...)
that's not really practical.
How is that an ideal solution? That is equivalent to saying "this problem
is hard, let's ignore it."
>
> Regarding the Haiku/Mac vs. Windows mode, how/where that is implemented
-- i.e. as a change to the keymaps or a flag for the input server -- is
really an implementation detail. I suppose a flag would be easier to
implement, but I don't care as long as it works correctly.
It won't be an implementation detail if we support multiple keymaps
because multiple keymaps break the control/command switching feature.
However, if we implement this in input server instead, it would no longer
have to. And while we are modifying input server to support this feature,
we could use this to also change the menu bitmaps too.
--
Ticket URL: <http://dev.haiku-os.org/ticket/7967#comment:22>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
