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

  • From: John Scipione <jscipione@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sat, 31 Mar 2012 10:36:41 -0400

On Sat, Mar 31, 2012 at 3:19 AM, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> John Scipione wrote:
>> On Fri, Mar 30, 2012 at 6:17 PM, Rimas Kudelis <rq@xxxxxx> wrote:
> [...]
>> To the system Right Alt and AltGr are indistinguishable. So
>> B_RIGHT_COMMAND_KEY = B_ALTGR_KEY. I believe, but am not 100%
>> positive, that the hardware sends an identical keycode for AltGr as
>> Right Alt. The keys cannot be distinguished from each other based on
>> what the hardware reports. At least it seems that way from what I've
>> read. This means that you can't map both a Right Alt and an AltGr key
>> to different keys on the same keyboard since the hardware sends an
>> identical keycode there is no way to differentiate the two.
>
> Maybe I misunderstand something, but I would say you got it the wrong way 
> around. The mapping is from physical key code to key role. 
> B_RIGHT_COMMAND_KEY and B_ALTGR_KEY are key roles and I don't see any reason 
> why they should be equal. This also means that you could very well map 
> different keys to B_RIGHT_COMMAND_KEY and B_ALTGR_KEY. Or, the more relevant 
> case, map the same physical key to either B_RIGHT_COMMAND_KEY or B_ALTGR_KEY 
> depending on the keymap.

OK

>> I have to check to see if your
>> keymap is >= version 4, and decide whether or not to handle the key
>> combo or not. If left alt, do the default, if right, do the AltGr
>> thing. This would be easier if AltGr produced it's own keycode, but,
>> like I said, I don't believe it does.
>
> This sounds complicated and totally unnecessary to me, since 
> B_RIGHT_COMMAND_KEY and B_ALTGR_KEY should not have the same value.

I can make B_ALTGR_KEY a separate value. I assume that means that it
should not fall through, meaning that you shouldn't be able to use
B_ALTGR_KEY for shortcuts?

>> >> On Fri, Mar 30, 2012 at 1:00 PM, Rimas Kudelis <rq@xxxxxx> wrote:
>> > 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?
>>
>> No, that's the point, there are no programs the differentiate between
>> Right and Left Alt in regards to shortcuts. They all specify
>> B_COMMAND_KEY which is equivalent either B_RIGHT_COMMAND_KEY or
>> B_LEFT_COMMAND_KEY. And since B_RIGHT_COMMAND_KEY = B_ALTGR_KEY it
>> also matches. What this means is that I have to check to see if your
>> keymap is >= version 4, and decide whether or not to handle the key
>> combo or not. If left alt, do the default, if right, do the AltGr
>> thing. This would be easier if AltGr produced it's own keycode, but,
>> like I said, I don't believe it does.
>
> This sounds complicated and totally unnecessary to me, since 
> B_RIGHT_COMMAND_KEY and B_ALTGR_KEY should not have the same value.


On Sat, Mar 31, 2012 at 8:09 AM, Rimas Kudelis <rq@xxxxxx> wrote:
> Hi,
>
> 2012.03.31 03:03, John Scipione rašė:
>
>> On Fri, Mar 30, 2012 at 6:17 PM, Rimas Kudelis<rq@xxxxxx>  wrote:
>>>
>>> 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.
>>
>> Well, not falling through would be easier for me, but, I disagree,
>> shortcuts should fall through. I suppose I could be persuaded
>> otherwise. I don't have a really good reason to want them to fall
>> through I just figured it is the polite thing to do.
>
> I think these should be treated as distinct keys with distinct functions and
> AltGr should not fallback to something else. It could probably be used with
> Ctrl or Cmd shortcuts as you said, but that would be quite unconventional (I
> guess at least partly due to the fact that not all keyboard layouts need and
> have AltGr).

OK, I'll make them separate key roles with no fall-through.

>>>> On Fri, Mar 30, 2012 at 1:00 PM, Rimas Kudelis<rq@xxxxxx>  wrote:
> As Ingo explained in his email, I'm just suggesting for the B_ALTGR_KEY
> constant to be different than B_RIGHT_COMMAND_KEY, and to let the keymap
> author decide which one of those constants the physical key press returns.
>
> To illustrate it better, here's a part of your layout's header:
> Version = 4
> CapsLock = 0x3b
> ScrollLock = 0x0f
> NumLock = 0x22
> LShift = 0x4b
> RShift = 0x56
> LCommand = 0x5d
> RCommand = 0x05f # Isn't 05f a mistake, BTW?

0x5f is normal for right command = right alt

See here for confirmation:
http://haiku-os.org/legacy-docs/bebook/TheKeyboard_KeyCodes.html

> LControl = 0x5c
> RControl = 0x60
> LOption = 0x66
> ROption = 0x67
> Menu = 0x68
>
> My point is why not make it like this for US-International:
> Version = 4
> CapsLock = 0x3b
> ScrollLock = 0x0f
> NumLock = 0x22
> LShift = 0x4b
> RShift = 0x56
> LCommand = 0x5d
> RCommand = 0x00 # No key is assigned to RCommand
> AltGr = 0x5f # 0x5f is AltGr
> LControl = 0x5c
> RControl = 0x60
> LOption = 0x66
> ROption = 0x67
> Menu = 0x68

OK

>
> And then like this for US-domestic:
> Version = 4
> CapsLock = 0x3b
> ScrollLock = 0x0f
> NumLock = 0x22
> LShift = 0x4b
> RShift = 0x56
> LCommand = 0x5d
> RCommand = 0x5f # 0x5f is RCommand
> AltGr = 0x00 # No key is assigned to AltGr
> LControl = 0x5c
> RControl = 0x60
> LOption = 0x66
> ROption = 0x67
> Menu = 0x68

OK except US-domestic will remain version 3 most likely.

> I had this idea, which I think gained some popularity among people I shared
> with, to use Win (Opt) keys for system-wide shortcuts, like in Windows.
> Having these keys would not be necessary, yet they would be a nice addition.
> IMO, it would be a bit dumb to call those keys Opt, but that's a different
> issue.

Perhaps I am stuck in a backwards mindset but I always thought that
the option layer was meant for special characters and not shortcuts.
Although now that AltGr exists I suppose that could be revised.

>>> 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  –
>>
>> I am of the opposite opinion because either Alt and AltGr are
>> guaranteed to be there, Option is not. Besides, you can still use
>> Option combined with Alt and/or control for shortcuts, just not option
>> and option+shift alone.
>
> Well, first, the user can map those keys manually in the keymap preflet, so
> it's not like you're making anything absolutely inaccessible.
>
> Second, you can't deny that 99% of the keyboards currently in production
> have at least one Windows key (or have Mac Command keys), so while in theory
> their lack could be a problem, in practice, that would be very rare. And
> yes, I am aware that some Haiku developers are psychologically attached to
> their 10-or-so-year-old keyboards :), but I think they could simply choose
> different keys for Opt manually, or live without some of the few Opt
> shortcuts.
>
> By the way, I believe that BeOS keyboard layout (specifically, the
> Command/Option/Control keys) was modeled after that of Macs and then had to
> be re-fit onto a 101-key PC keyboards of the time (Windows keys were
> probably just beginning to appear), which is why it's so "upside down" in
> the first place. But while Haiku is modeled after BeOS, I don't think it
> should be restricted by the same constraints, that are no longer valid. At
> least one Win or Command key is supplied with pretty much every keyboard
> now, so why hesitate?

Laptops tend to have fewer keys much of the time, even modern ones. If
you looked hard enough I'm sure you could fine one that didn't have a
Windows key. So, we can use the key, just not for "essential
functions", same goes for Menu.

I know some people like to use IBM Model M's which have no Option keys
at least, although I suppose those users could pony up for a Unicomp
to get those keys.

> Third, I guess it's more of a naming issue. In Linux and Windows, AltGr
> enters funky or not so funky characters, and plain Alt is a shortcut
> modifier (ALTernative/OPTional shortcut), so I think it would make sense to
> identify the layer that enters funky characters as AltGr and the one used
> for shortcuts as Opt or Alt (since Opt is Alt on Apple keyboards and does
> not exist elsewhere). Then, you can assign those layers to whichever
> physical keys you like by default. Even currently, the Haiku keymaps which
> traditionally use AltGr, have the right Option function assigned to the
> AltGr-key, not the right Win-key, which gets the function of right Command.
> So it's not like you would be changing a lot.

I guess that could work. I like the idea of having some additional
special characters in the opt layer, even though AltGr exists. But, if
it is designated for use with another function like system wide
shortcuts I could live with that. Somebody has to make that decision.

> They aren't taken in Haiku yet, because there's no AltGr yet. I don't
> understand how something that does not exist yet can already be taken. :P

I suppose that I could map my version of option onto AltGr for
US-International, but, that would be quite a change to people used to
how AltGr currently (kinda) works so I won't do that. I'll create a
new keymap that uses my version of option in AltGr.

> Like I said, I was suggesting to remove that layer from the text file only.
> Or even better – make it optional. I think it could be autogenerated during
> compilation in most cases. E.g. if a key enters a and A in levels 1 and 2
> respectively, you can deduce that in Ctrl layer, it would enter ^A. This
> layer could still be compiled into the binary layout file.

That is certainly possible, provided Control is universal.

John Scipione

Other related posts: