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

  • From: Rimas Kudelis <rq@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sat, 31 Mar 2012 01:17:53 +0300

Hi,

2012.03.30 23:45, John Scipione wrote:
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.

I believe falling through is a wrong design decision. There is no falling through in Windows or Linux, and I think it's quite understandable, since the keys are simply different.

It would make sense though if the keymap could define whether the key is Ralt or AltGr. Keymaps with level 3 would define it as AltGr, while keymaps without it (the US one) would define it as Ralt. This way the keymaps that don't need AltGr would simply have two Alt keys instead of one. That's the way both Windows and Linux do that (although, for legacy reasons, Windows thinks AltGr is the same as Ctrl+Alt).

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 don't really understand what shortcut combinations with Right Alt you are talking about. Are there programs that differentiate between LOpt and ROpt in shortcuts? Either way, freeing up the Opt layer would make it all clean and available for the programs. On the other hand, cluttering it with duplicate dead key definitions that already exist in AltGr... it would just make it harder to predict.

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.

I don't really understand. AltGr did not exist as a separate key in Haiku up until now, so it could not have separate mappings.

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.

I ran a quick test when writing previous email. What I wrote was my conclusion. You mentioned you're from Canada, right? Could it be that you're confusing some Canadian layout with the US one?

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.

Which ISO standard do you refer to? Neither of your layers seems to match the ISO 9995-3 standard, the image of which you can see in http://en.wikipedia.org/wiki/ISO/IEC_9995#ISO.2FIEC_9995-3.

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.

I must confess I haven't looked at what Haiku currently has (too lazy to boot and look).

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.

Oh god, I feel like Haiku developers treat the world upside down when it comes to keyboards...

I think my wish is similar to yours, except I want the option layer to be reserved for app shortcuts, and AltGr to act as it does in Win/Lin – that is, to act as a level chooser, not as a meta-key. I'd say you can clutter the AltGr and AltGr+Shift levels all you want, just leave Opt empty, to be used for shortcuts.

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.

I don't quite understand why you say you can't move them from Opt to the same places in AltGr. Is it because of the ISO standard?

At least the one I refer to (specifically, the really old version 1 of it) is a bit funky. It actually talks about "Complementary groups" and methods to toggle between the groups. However, I think it's a bit outdated in a sense, because group toggling has been implemented differently than it says in all the operating systems I know of. All of them (except vanilla Haiku, perhaps) have the ability to change keyboard layouts with simple key combinations, and I think that that is pretty much the same as group toggling defined in the standard.

The same standard talks about a "Common secondary group layout", which I linked to above. While it's a nice thing to have, I don't think it's worth dedicating yet another function/action/control key for it. Considering the limited number of keys in the keyboard, wouldn't it make sense to simply define that "Common secondary group layout" as an ordinary layout in Haiku, and have it available in the keymap preferences for those who need it? This way those who need it could switch to it with a key combo, and those who don't need it, could simply ignore it. And the Opt key would be free for shortcuts!

Another fact in my favor: even if you make Opt act as a group shift for that layout, entering Level3 symbols from that group would be awkward: you'd have to keep both Opt and AltGr pressed while pressing the character key.


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.

Well, you're introducing the new version of keymaps anyway, so I thought, why not?

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.

Thanks!

Rimas

Other related posts: