[haiku-development] Re: AltGr Key, key_map, and the US-International Keyboard

  • From: Rimas Kudelis <rq@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Thu, 29 Mar 2012 22:29:08 +0300

Hi,

2012.03.29 21:35, John Scipione rašė:

On Thu, Mar 29, 2012 at 1:44 PM, Rimas Kudelis<rq@xxxxxx>  wrote:

2012.03.29 11:48, John Scipione rašė:


I have also updated the US-International Keymap with new keys. I moved
the current option settings to right option and filed out the right
option based on the keys produced in Mac OS X (with a little BeOS 5
thrown in).

First of all, with AltGr layer available, I don't think Option layer is
needed.

I believe that it is for some keymaps like French but François Revol
can chime in and correct me if I'm wrong.
I believe Haiku keymaps have been using the Option layer to enter special/accented characters simply because the AltGr layer was unavailable. For me, it's actually easier to think of your change as Option being renamed to AltGr, and the other function (Option) being decoupled from it rather than AltGr function being decoupled and taking with it almost everything that Opt has been doing. So what we had in the Option layer, we now simply move to the AltGr layer, and then the Option layer becomes empty. 


At least with the
US-International keyboard it is something that is nice to have since
you can access special keys in different ways. For instance to product
ñ you can type left-option+N followed by n using the tilde deadkey, or
you can type right-option+n to get the letter
There's a line somewhere between "this is really powerful" and "it's just complicating things with no benefit". I tend to think that adding more layers crosses that line, although I'm probably a bit biased because for the languages I use, two modifiers (Shift and AltGr) are enough. I just don't think an average user would benefit from having 6 or 8 layers in her keyboard to enter accented characters. :) That's what dead keys are for. 


Subsequently, I don't think Option and Control layers should belong
to the keymap at all. At least the Control layer seems to output low-level
stuff. Is there any reason why it should be localizable and not hardcoded
(or at least not autogenerated)? Same goes for the Opt-layer, if it were to
be used for application shortcuts as you suggest below.
Making the Opt layer unavailable in the keymap definition source file and
replacing it with an AltGr layer would allow to retain the compatibility of
keymap source files. Making Control layer unavailable too would render
current definitions incompatible, but would also make the new format
cleaner.

For the control layer perhaps it could be eliminated if it truly is
standard across all keyboard varieties and never changes. But, I can't
say that for sure and having it in the keymap doesn't really hurt
anything.
Well, it hurts a bit by uselessly complicating the keymap source file and being a potential error vector. I don't mind it being in the binary keymap files, but since it's not likely to be changed, I think it would make sense to have it omitted from the source files. 


As for as the Opt-layer, generally shortcuts use Command (Alt by
default), very few utilize Option alone. But, I could remove mappings
of less-used characters in the Option map in order to facilitate using
option for shortcuts combos. My thinking was, Option (Windows by
default) is the special character key. If it is used as a shortcut key
generally it will be combined with Command so I am free to use option
alone (or combined with shift) for special characters. There may be
some exceptions to this, if so, I'll prune the option map.
Oh, I thought you were thinking about giving Opt a function similar to Alt in Windows (toggle access keys). Although with touchscreens and stuff, it just might fall out of fashion before Haiku evenmhits the shelves... :)
OTOH, I assume Option alone is not used for commands precisely because it's been designated as AltGr all the time. With these functions split, there are new possibilities. 



I also realize that AltGr is usually right Alt not right option,
but, I figured assigning it to right option would cause
less conflicts and would free up the right alt key for use with
application shortcuts instead. Maybe a better name than AltGr could be
used.

It definitely does. Here's a spark for a flamewar: how about renaming those
keys to Alt and AltGr? PC's, which are the primary target of Haiku, don't
have Opt keys on their usual keyboards anyway, and Opt->Alt rename would not
hurt compatibility as it would be just a cosmetic change. Technically,
L3Shift would probably be more appropriate for AltGr, but the "Computers
don't have it" argument could be applied here as well. AltGr is just a
commonly known name of that key.

Unfortunately the Alt and AltGr keys are assigned to Command, not
Option so AltGr might even be actively confusing.
Nope, and this has been annoying me for a long time. For keymaps that traditionally use AltGr, Haiku makes AltGr key act as Option by default (meanwhile the other Option is the left Win-key). So renaming that key to AltGr would only make sense. The US keymap is different in this sense. Both Win keys act as Option in the US keymap, because US doesn't use AltGr traditionally. 


I like the idea of calling the map shift-level-3. That is unambiguous.
"Level 3 Select" would be the appropriate name of that key per ISO/IEC 9995, but like I said, you won't find such label on any keyboard, so, while standards-compliant, this might as well be confusing. 


By the way, a keymap file attached to http://dev.haiku-os.org/ticket/6546
crashes the keymap utility. I've debugged it and it appears that some of my
definitions (e.g.
http://dev.haiku-os.org/attachment/ticket/6546/Lithuanian.keymap#L209) are
simply too long. Is there any chance of you looking and fixing that problem
too, please?..

I looked at the Lithuanian.keymap file you posted and lines 80-90 do
not end in a space. I was just messing with the /bin/keymap app (to
make it read and produce version 4 keymaps) and I am almost sure that
it requires there to be a space at the end of each line.
I actually managed to get to testing where that keymap failed a month or so ago, and it did reliably fail with long dead key definitions such as the one I showed you. I may have added the spaces you are talking about, but I don't think they are to blame.
You can try editing any keymap file. Paste line 209 to it, and the keymap app should crash, unless it's been fixed without me knowing. :) 


While I have your attention, would you be interested in helping me
produce a proper Lithuanian keymap in the style of the
US-International above? I have the information from
http://en.wikipedia.org/wiki/AltGr_key to go on, but, someone with
real knowledge of using a Lithuanian keyboard, knowing what characters
are useful and not, would be extremely useful.
I can help you, although the current Lithuanian keymaps are the ones to look at. I had them cleaned up recently, and all the characters it outpus in the Opt layer actually belong to AltGr. 

We could chat on IRC this weekend, my nickname is RQ. Should I plan that?

Rimas

Other related posts:

  1. Home
  2. haiku-development
  3. Archive
  4. 03-2012