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

  • From: John Scipione <jscipione@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Thu, 29 Mar 2012 17:19:33 -0400

On Thu, Mar 29, 2012 at 3:29 PM, Rimas Kudelis <rq@xxxxxx> wrote:
> 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.

Here is how you can get what you want:

Move all of the current option map settings into the altgr map and make the
option map blank. If you want AltGr to be produced by Alt instead of Win
assign right option to 0x5f and assign right command to 0x67.

Although in that case I don't see why you wouldn't switch both command and
option on the left and right sides for consistency. There may be a good reason
of which I am not aware.

>> 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.

I agree that the US-International keymap could get by with just an option
layer, and I would support that except for bug #2241 regarding dead keys.
https://dev.haiku-os.org/ticket/2241

The option map gets you dead keys, the AltGr map gives you the most of the
same characters without utilizing a dead key. Everybody wins, except shortcuts
that rely on option or option+shift without any other modifiers and I am
confident that that is not a big deal.

>> 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.
>

It is smart to keep control and option maps in the keymaps, just in case.
Yes, they make writing keymaps harder, but once written, are more flexible.

>> 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.
>
> "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.

I am trying to fix issues that have annoyed people (like me) for a long time!

The map is the level_3_select map, that might be a good name for use in the
key_map struct. As far as the user of Keymaps is concerned, AltGr might be
a better choice. Let's just call both altgr for now unless we can come up
with a better name.

Although the labels are meant to correspond to the key role, that is
B_CONTROL, B_OPTION, B_COMMAND, and not the key label. What is the name of
the role of AltGr? The idea is that the key role is unambiguous, but the
label changes based on keyboard and locale. Since I can't think of a better
name I say we just go with AltGr since that is common.

Version 3 maps could show show Command or Option on the right side, while
version 4 maps could show AltGr. The "American" keymap will remain version
3 since it doesn't feature AltGr nor does it ever need to.

>> 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 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 outputs in the
> Opt layer actually belong to AltGr.
>
> We could chat on IRC this weekend, my nickname is RQ. Should I plan that?

Yes definitely do. My nickname on IRC is Skipp_OSX. I'll be on #haiku this
weekend on Sunday at least, and probably late in the evening (for me,
anyway) too. So you'll be able to find me easily.

If moving the keycodes from the option map to the altgr map is the only change
then I can do it myself, but it still might be good to work through some ideas,
and I have lots of questions.

John Scipione

Other related posts: