[haiku-development] Re: Key roles vs. key label in menus
- From: John Scipione <jscipione@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 5 Apr 2012 14:46:02 -0400
Sorry to bring up this old discussion, but I am actually getting
around to doing the work now so that is why I am bringing it up again.
First of all, on the debate of Key roles vs. Key labels, Key roles wins.
I have ripped out the implementation of creating, deleting, and
accessing the menu bitmaps from MenuPrivate and put them into their
own new KeyRole class. The KeyRole class is in the BPrivate namespace,
so it is not a public class. However, I wanted the bitmaps for key
roles to be separate from MenuPrivate so that they could be accessed
(but not changed) from other places in the system besides the menus.
I changed the "ALT" bitmap to say "CMD" because it now represents the
Command Key Role and not the Alt Key label. SHIFT, CTRL, and OPT stay
the same. Changing keys in keymap does not alter which bitmaps show up
in the menu. This made everything a lot simpler. The bitmaps simply
get created on _init_interface_kit_ and deleted on
_fini_interface_kit_ and are only accessed by the menu in between.
They are static const bitmaps so never change and are only ever filled
out one time, not in each menu for obvious performance reasons.
Now, all that being said, re-reading the above discussion the idea of
using UTF-8 characters instead of bitmaps seemed like a good idea to
many people. The benefit of using a character rather than bitmaps is
that not only does the implementation become much simpler, but also
the symbols are internationalized. Using UTF-8 characters rather than
bitmaps would in-fact eliminate the need for the new KeyRole class.
The key is to find UTF-8 characters we can all live with. Several
people brought up some good points helping to eliminate possibilities.
Axel doesn't want Place of Interest ⌘ to be used for command because,
well, let's face it, it is too Apple-y and really, doesn't have
anything to do with command, it is more just a historical artifact. A
black diamond ◆ was suggested because it appears on old Sun keyboards.
It is a nice enough symbol, so I propose we use that or a white
diamond ◇ instead if the black diamond is too overpowering.
For Control a carrot ^ is fairly universal, but, as Adrien brought up,
will be confusing with using the actual carrot ^ character in
shortcuts, so, instead we should use either Black Up-Pointing Triangle
▲ or, if that is too overpowering White Up-Pointing Triangle △
instead.
For Shift Upwards White Arrow ⇧ seems to be the obvious choice. It
even appears on some keyboards.
For Option, as was stated previously, there is no obvious choice. But,
as was stated before my original suggestion, Option Key ⌥ is logical
and so I still say we go with that. If you have doubts, the actual
Unicode name for that symbol is OPTION KEY. So, it seems like a good
"option" to me. :)
John Scipione
Other related posts:
