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

  • From: John Scipione <jscipione@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Fri, 30 Mar 2012 16:45:57 -0400

On Fri, Mar 30, 2012 at 12:00 PM, Rimas Kudelis <rq@xxxxxx> wrote:
>> Well, if <AltGr> allows an access to a layer, don't forget that it should
>> be handled in a specific way : if <AltGr>+<Key> has no correspondences,
>> the <AltGr> key should FALL-BACK to the <Alt> key.
>> For instance, with the french "azerty" keyboard, <AltGr>+<T> should be
>> equivalent to <Alt>+<T>
>> This way you don't loose the second <Alt> key.
>
> I don't know where you got that idea from but it certainly does not work
> that way in Windows. And if it did, it would hurt consistency. I don't think
> falling back to Alt this is a good idea.

I have done some further re-architecting based on yesterdays discussion
assigning the AltGr key to right Alt key in the keymaps that have it
by default. BWindow currently eats any characters combined with B_COMMAND_KEY.
So, I updated BWindow to check if you have an AltGr key defined in your
keymap, and if so, I check to see if you have a key mapped in an AltGr table
for that character. If so, skip the shortcut, if not, process as normal.

For example, you have added a mapping for the 'f' key in the AltGr map so as
to make a fancy ƒ when you push right-Alt+f. If you type left-Alt+f
it will pick the find shortcut. However, if you type right-Alt+f it will
print ƒ.

Another example, if you do not have q mapped in the AltGr map and you type
either left or right-Alt+q it will skip the mapping and move to Quit
shortcut.

So in that way it does fall-through.

>> From: "Adrien Destugues" <pulkomandy@xxxxxxxxxxxxx>
>>>
>>> The idea of the extra AltGr modifier is (for French keyboard, at least) :
>>> * Ctrl key is used to enter control characters, from Ctrl + A = ASCII
>>> code 1 to Ctrl + Z = ASCII code 26, IIRC. These are technically regular
>>> ASCII characters.
>>
>> it's usually handled by the Terminal applications as it's a specific
>> behavior of text-based-command-line applications.
>
> Well, positions of A and Z may differ on different layouts. But I agree – I
> think it's Terminal's job to translate <Ctrl>+Z to ^Z.

Let's focus on one thing at a time. I am only concentrating on the AltGr key
right now. Forget control, it basically works, even if there are problems.


On Fri, Mar 30, 2012 at 1:00 PM, Rimas Kudelis <rq@xxxxxx> wrote:
> My point was that AltGr layer does not exist in Haiku as of yet, which is
> why accented characters ended up in the Opt layer. With the AltGr layer
> finally coming up (thanks to you), all stuff should be moved from Opt to
> AltGr, and that's it.

I'd also like to provide dead keys and some other special characters
via the Option key. Anything you define in the AltGr layer is taking away
potential shortcut combinations using right Alt, so that should be kept to
a minimum, but the option mapping is more free.

I will define dead keys in both the option layer and AltGr layer. That being
said, I can live with stripping the option layer if it is deemed necessary.
The characters are more "nice to have" than "must have".

> I can only agree with the comments on that ticket: the way US international
> behaves is intentional. The only problem is if US international is the
> default. The default should be changed to US then, or, even better, to
> depend on locale in use.

I could see American/US keymap being more useful if it also specified the same
keys in the Option layer as US-International but did not specify the AltGr
mappings. Ultimately the "default" is based on an install time choice.
US-International is fine as a fall-back default.

>> 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.
>
> Sorry, but I don't think it was the right thing to do, for multiple reasons:
> 1) the way US international keymap behaves is the same way it behaves at
> least in Windows (I haven't checked other OS yet, but can check Linux if
> anyone wants me to)

I doubt that is true, at least in regards to dead keys in the normal map.

> 2) You can only have one precomposed accented letter on each key in one
> layer. Your N example was quite convenient, but what about e.g. letter a?
> Will you put ã or à in A's AltGr layer?

In the AltGr layer there are several a's mapped: ä, å, and á based on the ISO
standard. Same goes for i, u, o, and there is also a ñ. Once I turn dead keys
on in AltGr, you'll be able to get many of the same dead keys from different
characters via the AltGr Layer. There is some repetition, which is a good thing.

> The letters in AltGr and AltGr-Shift
> layers in your screenshot are only slightly related to those in normal and
> Shift layers. This means the user would just have to memorize them, which I
> think is harder than just use the dead key occasionally.

The letters in the AltGr and AltGr-Shift layers in my screenshot are exactly
the same as are in the Option layer currently. Dead keys are no defined
though, I'll change that.

> 3) If you want everyone to win, why not just move the dead keys to AltGr and
> AltGr-Shift layers of the appropriate keys?
> This wouldn't be the same US
> international keymap as the one in Windows, but it would allow you to type
> tilde and other characters as usual, while you would know that AltGr+Tilde
> is a dead tilde. Everybody would win, and you wouldn't need to have symbols
> in the Opt layer. And apps could actually rely on Option+key or
> Option+Shift+key even more than they can now (because now Option+key can
> enter a symbol, and with that change, it would not).

I do not want to clutter the AltGr maps with anything that is not part of the
ISO standard because I want keys not defined in the AltGr map to be used for
shortcuts. In fact I've removed some keys in the screenshot that are not part
of the standard.

Also I want to keep the dead keys in the positions I defined in the option map.
There is a method to it. Acute is e because é is common, Tilde is n because ñ
is common, etc. I could not simply move the dead keys defined in the option
layer over to the AltGr layer in the same places, which is why I defined them
in option instead. However, I'll define them in AltGr too, and they will appear
in other places. So you'll be able to access dead keys either by option or
AltGr. The user can pick the one he or she likes better.

>> 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.
>
> "Just in case" is a weak rationale, IMO. You could say "it's smart to do X,
> just in case" about pretty much anything. I think it would be smarter to
> actually evaluate the needs. Has anyone from the Haiku team ever done
> anything unusual in the Control layer? Would you want anything unusual in
> the Opt layer, if you had AltGr as a separate layer?

You are probably right that the control map is never defined in more than
one way in practice. Let's call it legacy instead since removing control
would break existing keymaps and applications.

>> I am trying to fix issues that have annoyed people (like me) for a long
>> time!
>
> Yeah, and it seems like I have a lot of convincing to do too... :)

Well, hopefully not as much as you think. I've taken much of the advice you
have given so far seriously. I want to get this right.

John Scipione

Other related posts: