AltGr should have a separate keycode

[rq]

This is a spinoff of #6364.

Currently, the Opt key maps to two different PC keys: Alt and AltGr. This is similar to Macs and same as original BeOS, but it could probably be better if these two functions were actually separated. AltGr function (which is actually just a Level 3 Shift) should probably have a separate keycode.

[rq]

Note that there are two OPT keys, but no ALTGR or L3SHIFT in the screenshot.

[pulkomandy]

After a quick look at the API, we currently have 16 allocated bits in the modifier enum, and the API seems to use an int32 everywhere, so we could add a "B_LEVEL3_KEY" without breaking anything.

[siarzhuk]

Replying to rq:

Currently, the Opt key maps to two different PC keys: Alt and AltGr.

Have you mistyped here and meant Win and AltGr keys? Because Alt key has Command assignment by default and AltGr is a typical way to enter Optional layer in the european keymaps. By the way, I think that this "Win => Opt" assignment has occured during porting BeOS from PPC to x86 platform.

This is similar to Macs and same as original BeOS, but it could probably be better if these two functions were actually separated. AltGr function (which is actually just a Level 3 Shift) should probably have a separate keycode.

In my opinion the Win key is the first candidate for separate keycode in such case. But I do not understand which profit do you get from this? Additional Win-layer in keymap? :-D

[rq]

Replying to siarzhuk:

Replying to rq:

Currently, the Opt key maps to two different PC keys: Alt and AltGr.

Have you mistyped here and meant Win and AltGr keys? Because Alt key has Command assignment by default and AltGr is a typical way to enter Optional layer in the european keymaps. By the way, I think that this "Win => Opt" assignment has occured during porting BeOS from PPC to x86 platform.

I didn't mistype. I meant the OPT function. I should've been clearer about that. However, the way those assigments are shuffled right now is IMO ugly and undesirable. That's what #6364 is about.

This is similar to Macs and same as original BeOS, but it could probably be better if these two functions were actually separated. AltGr function (which is actually just a Level 3 Shift) should probably have a separate keycode.

In my opinion the Win key is the first candidate for separate keycode in such case. But I do not understand which profit do you get from this? Additional Win-layer in keymap? :-D

The short answer is: I don't care at all about additional layers on the keyboard. IMO, two modifiers – Shift and AltGr – are enough for most if not all cases, or at least that's the most common scenario.

I don't know what else OPT key does apart from adding additional keymap layer and modifying keyboard shortcuts. If these are all the functions is has, then yes, maybe it's not so useful to separate them.

The long and much broader (to the extent that it could be considered offtopic) answer follows...

I'm not sure about what other functions than providing additional layer the Opt key has in BeOS/Haiku. If that is all it does, then perhaps it's OK to keep this as is. However, this solution should not be made in a vacuum. Since we have a limited number of keys, we have to see all the distinct functions that the function keys perform, because we will have to combine them (assign more than one function to the same key). The most common functions I could think of are:

	Key
Function	Windows/Linux	Mac	Haiku*
App Command	Ctrl	Cmd	CMD
Control	Ctrl	Ctrl	CTRL
Option	Alt	Opt	OPT
Mnemonic Access	Alt	-	-
Level 3 Shift	AltGr	Opt	OPT
OS Command	Win/-	Cmd	-
OS Menu	Win/-	-	Menu
Context Menu	Menu	-	-

Note: to avoid a mess (#6364), in Haiku column I used key names as shown in the screenshot, not the actual names on keyboard.

I think the key to a good solution here is to actually decide which of these functions we want to use, which ones we are using and which ones we don't care about. Also, different functions should be combined in a sane manner, so that they clash as rarely as possible.

Here's a table of functions that I think could coexist on the same key. Letters W,L,M,H mean that the combination is already used in Windows, Linux, Mac, and/or BeOS/Haiku:

	App Command	Control	Option	Mnemonic Access	Level 3 Shift	OS Command	OS Menu	Context Menu
App Command		W,L				v
Control	W,L		v	v				v
Option		v		W,L	M,H		v	v
Mnemonic Access		v	W,L					v
Level 3 Shift			M,H
OS Command	v						W	v
OS Menu			v			W
Context Menu		v	v	v		v

Note: this table is based on assumption that Control is only useful in Terminal, and Option only modifies keyboard shortcuts.

Another note: I separated OS Command from App Command keys, like it's done in Windows. I personally like that because it means the OS can introduce new global keyboard shortcuts without affecting applications. E.g. Win+F fires up a global Search dialog in Windows, while Ctrl+F usually fires the application's Find dialog. OTOH, if there's a really small number of OS commands, then maybe Fx are the right keys to use for them (like in OS X), and a separate OS Command key is not needed. I also don't know if such thing currently exists in Linux or Haiku.

The goal would be to have no more than one H in each row and column.

As a "frequent flyer" between Windows, Linux and Mac, I would see another goal: consistency with other operating systems. We should not assume that Haiku is the only OS the user uses, so not punishing them for having some muscular memory is a good thing. In that regard, Mac and Haiku aren't really friendly to Windows and Linux users ATM. And since Windows is currently the dominant OS, I'd rather be consistent with Windows than with Mac. Also, just by looking at first table, it's pretty obvious that Windows is the only OS currently providing all of the listed commands, and that Linux is mostly consistent with Windows in this regard.

Windows and Linux combine App Command and Control onto the same key. I think it makes perfect sense to do so, because Terminal is usually quite an ascetic application with just a few commands in need of a shortcut key, so Terminal could simply be an exception from the usual keyboard shortcut consistency rule and use slightly different shortcuts (as is done with Gnome terminal - it simply assigns Ctrl+Shift+key to functions where Ctrl+key is the usual combo). Futhermore, Terminal is usually a power-user application, so we can expect them to know that Copy is not CMD+C in Terminal.

I wrote so much stuff here that I forgot my initial idea. However the bottom line is this: At most, we only have 7 keys that we can use for all those (and maybe even more) functions, so we will have to combine these functions. And I'd rather see them combined in the same way they are in other popular operating systems than in some other way unless that other way is considered better (and not just for legacy reasons). It seems like Windows alone currently has 90% of the OS market share, so I'd rather see Haiku pleasing Windows than Mac users' muscular memory.

Pulkomandy, I guess you should not introduce any new keycodes until we have clear answers to the questions above.

[pulkomandy]

As for terminal, I'm forced to disagree with the above :

• Power-users are the one using keyboard shortcuts
• Power-users also rely a lot on their muscle memory (at least I do)

Introducing different keyboard shortcuts in terminal is annoying, particularly for functions like control+c = copy. I see no good reason to use anything else. I tend to use my left hand only to type these shortcuts, and the linux way, control+shift+key :

• Is very difficult to reach, while alt+key works fine
• Does not work under windows, so it doesn't help anyway ;)

In a more general view, double-modifier shortcuts are evil.

Anyway, all of this is unrelated. Currently there is no way to differenciate AltGr from "Win" key (or Alt from AltGr, depending on the keymap). The choices are :

• Introduce a new modifier key that could have an use as pointed out by rq above (win+f = OS find, stack and tile, switching workspaces, whatever WM shortcuts or OS shortcuts). This extra modifier would never be used in BeOS apps, so it could be reserved to the OS. It could even be intercepted somewhere so apps never hear of it.
• Keep the key as a regular key and not a modifier. This means the key has a use on its own (for example opening the menu), and can be used with modifiers like shift+win or alt+win. This is not really useful, I think.
• Make it a compose key. ​http://en.wikipedia.org/wiki/Compose_key . This can have its uses, too, allowing to write chars that are otherwise missing from your keymap. Sometimes I have to write in spanish with my french keyboard and lack some of their characters. I don't want them to be easily available, but with compose it would be easier to reach them.

[rq]

Replying to pulkomandy:

As for terminal, I'm forced to disagree with the above :

• Power-users are the one using keyboard shortcuts
• Power-users also rely a lot on their muscle memory (at least I do)

Introducing different keyboard shortcuts in terminal is annoying, particularly for functions like control+c = copy. I see no good reason to use anything else. I tend to use my left hand only to type these shortcuts, and the linux way, control+shift+key :

• Is very difficult to reach, while alt+key works fine
• Does not work under windows, so it doesn't help anyway ;)

In a more general view, double-modifier shortcuts are evil.

One of the things I wanted to say by my comment was: having a key (even two keys sometimes!) in the keyboard that is ONLY used in Terminal is suboptimal. And if CTRL is only used in Terminal applications, then it should not exist as a separate key. I'd rather solve each conflict on a case-by-case basis and live with that annoyance than have a key in my keyboard that is only used by terminal applications (I'd see these as even less native than Qt-based applications). And by the way, Ctrl+Shift+C is not so hard to reach, because Ctrl and Shift are right next to each other. On my laptop, even Ctrl+Shift+P is easy.

Anyway, all of this is unrelated. Currently there is no way to differenciate AltGr from "Win" key (or Alt from AltGr, depending on the keymap).

Whatever the physical keys are, this bug is not about them.

The choices are :

• Introduce a new modifier key that could have an use as pointed out by rq above (win+f = OS find, stack and tile, switching workspaces, whatever WM shortcuts or OS shortcuts). This extra modifier would never be used in BeOS apps, so it could be reserved to the OS. It could even be intercepted somewhere so apps never hear of it.
• Keep the key as a regular key and not a modifier. This means the key has a use on its own (for example opening the menu), and can be used with modifiers like shift+win or alt+win. This is not really useful, I think.
• Make it a compose key. ​http://en.wikipedia.org/wiki/Compose_key . This can have its uses, too, allowing to write chars that are otherwise missing from your keymap. Sometimes I have to write in spanish with my french keyboard and lack some of their characters. I don't want them to be easily available, but with compose it would be easier to reach them.

Since we don't yet agree here, I suggest to resolve #6364 first, making both Win, both Ctrl and both Alt keys equal at least for now, and then revisit this bug. I guess you'll be complaining about the fact that you'll only have OPT (AltGr) key on your left side then, but that's Alt-as-a-shortcut for you. :P

By the way, I also had Compose in my head. But again, we only have a limited number of keys, so we probably shouldn't introduce it without evaluating what we have and what we want to have first.

[pulkomandy]

I agree that AltGr and Win should not be the same modifier, but Alt and AltGr should not either. That's why it is impossible to fix #6364 without introducing something else. The question here is not directly what this key should be used for, but how, API-Wise, it should be reported to applications. Possible answers are :

• Not reported at all : the key would only be used by the OS. No API change.
• Reported as a modifier : the key can be used by everyone. API change as the modifier status will have more defined bits. It can act as a shortcut modifier, a level-4 key, or anything else. Needs a change to the keymap format if we go level-4, and also makes way too much symbols on each key
• Reported as a regular key like q,w,e : not sure what that would be useful for
• Not reported, used as a compose key : no API change, works like a special dead key.

These 4 solutions require different code, but all solve this issue. I don't care about how the "new" key is used, but only the fact it can be reported to someone.

If we fix #6364 now, it would lead to :

• both CTRL keys > Control
• both Win keys > Option
• left alt key > Command
• AltGr (right alt) key > Option
• Menu key > Menu

This is somewhat better than the current scheme, but leads to 3 keys (winL, winR, altGr) doing the same. Now what to do with that : on AZERTY keyboards people will use AltGr as Option, so they'd want Win to be the key doing 'something else'. On US-QWERTY, there is no AltGr key so I think people actually use Win as Option. They would want AltGr to do 'something else', and have this 'something else' not mapped on their keyboard.

The problem with all that is the AltGr key is not present on all keyboards, so you can't assign it a meaning that's vital to the use of the system. Some time ago it was also the case of the Win key. This likely explains why they share the same non-vital function, in the hope that every keyboard would have at least one of them. Now, time passed and it would likely be ok to rely on Win-key always being present. Can US guys live without level-3 shift ? Likely : the American keymap don't even use it. Is it ok for all countries ? I think so : the one that need it do have the altGr key.

[rq]

Some quick answer:

Re #6364: I think Alt and AltGr could do the same, for now. I would favor marking them both as Option keys, and marking both Win keys as Command. Both Ctrl-keys could then be called Control, at least for now. I'm pretty sure this change would be a hot topic among those few hundred BeOS veterans, but it would greatly reduce confusion for anyone with muscular memory coming from a different platform AND guarantee that you do have the AltGr functionality in the right place (the AltGr key).

As you can see, Macs (and BeOS boxes) had never separated Alt and AltGr functionality, they just have one or two Opt-keys, so having two keys with AltGr functionality wouldn't surprise me a bit.

Re AltGr (Right Alt) key: I believe that most, if not all, keyboards and laptops (except some from Apple) have it. In some cases it's marked as plain Alt, but that's not important, as the scancode is different (even on Apple keyboards). The only potential problem is that some older Apple laptops didn't have Right Alt at all (they have Enter key instead – see ​this pic). Luckily, Apple doesn't do this anymore, so we're saved!

[pulkomandy]

That would definitely be wrong.

We use Alt Gr as a level 3 shift, and it should stay that way. We use Alt (in the default settings) as Option to trigger the shortcuts, and it should stay that way too. That's just how a keyboard is meant to work.

The AltGr key is meissing from american keyboards, but they don't use it. They have two Alt key instead, and our americal keyboard reflects that.

What happens is actually that BeOS never used the "Win" key. It happens to be mapped as a level 3 shift for now, and that's what should be changed, freeing that key for other uses (no one uses it as lelvel3 shift anywhere, anyway).

There is no way Alt and AltGr doing the same is ever goig to work. Some people use keyboards that don't have the windows key (mmu_man still has his IBM Model M keyboard, for example). The win-key is a key you are allowed to move and do anything with. Making alt and alt-gr do the same thing would get everyone lost. Not only BeOS users, but also every azerty user. It's just plain logical that altgr is the level 3 shift and alt trigger keyboard shortcuts. Don't create problems where there isn't any.

The win key should be assigned some meaning that is both useful (because we want to use it) and not vital (because it's missing on some keyboards). That's the only thing to do, no need to mix up everything else and get everyone unable to type under BeOS. You were annoyed by ctrl and alt being swapped wrt to Windows, and that's ok, but it only affects power users that use keyboard shortcuts at all. Changing the meaning of AltGr basically prevents reaching 1/3 of the characters on an Azerty keyboard. People are going to be lost, and this will affect 2-finger typers as well as profesionnal 10-fingers-or-more ones.

AltGr is the level3 shift (or "option" in the current terminology). Alt is the command key. Ctrl is the control key.

These are the 3 mandatory keys to use a keyboard and they are always there when needed. Old macintosh keyboard don't have AltGr (even today), but they don't need it either : their azerty is slightly different (called French (Mac) in Haiku), and it uses alt+shift+key for the extra chars, placing them elsewhere on the keyboard. This is also the layout used on the amiga and similar to the azerty layout of other machines (Amstrad CPC...).

Now, there is an extra key, that happens to be on most modern Pc keyboards : the Win key. Despite being mapped to 'something' in the current keymaps, this key has absolutely no use as of now. As this key is available on *most* keyboards, but not *all*, you can't rely on it. So you can't make it the only option key available, nor the only command key : that would just make most BeOS apps shortcuts unuseable for some people. It can't be assigned to WM actions like stack-and-tile, because these aren't even reachable with only the mouse. As we didn't find an use for this key, we mapped it in a way that could be useful to some people. In American keymap it is the level3 shift, actually not doing anything ; for others, the level 3 shift was already mapped to AltGr, so the left Win was mapped to level3, while the right Win was mapped to Option. This is the only choice that can be played with. Moving any of the other keys would prevent use of some part of Haiku for some people.

[rq]

Replying to pulkomandy:

That's just how a keyboard is meant to work.

Can we make this statement a little softer? Like "That's how Haiku devs expect the keyboard to work"?

The AltGr key is meissing from american keyboards,

I'm confused: do you mean the physical keybaords or our layouts? Because like I said, American keyboards DO usually have two Alt keys, and they have different scancodes. The only thing they lack are the "Gr" letters on the key.

What happens is actually that BeOS never used the "Win" key. It happens to be mapped as a level 3 shift for now, and that's what should be changed, freeing that key for other uses (no one uses it as lelvel3 shift anywhere, anyway).

There is no way Alt and AltGr doing the same is ever goig to work. Some people use keyboards that don't have the windows key (mmu_man still has his IBM Model M keyboard, for example). The win-key is a key you are allowed to move and do anything with. Making alt and alt-gr do the same thing would get everyone lost. Not only BeOS users, but also every azerty user.

It wouldn't hurt for AZERTY users if you changed the assignment of Alt, not AltGr. By the way, the usual Lithuanian layout also makes heavy use of AltGr and AltGr+Shift layers, so I really DO know what I'm talking about.

By the way, I can't understand why retro keyboards should be a deciding factor here. I don't mind mmu_man loving IBM Model M, but I don't see a reason why such old models should keep Haiku from progressing. Not having a Win-key on your keyboard is something you have to opt-in for nowadays, not the default. IMO, mmu_man could just go to Keyboard preferences and adjust them.

It's just plain logical that altgr is the level 3 shift and alt trigger keyboard shortcuts. Don't create problems where there isn't any.

Well, Alt+C for copy doesn't sound logical for me. I agree that it does sound logical for long-time BeOS/Haiku users though.

The win key should be assigned some meaning that is both useful (because we want to use it) and not vital (because it's missing on some keyboards). That's the only thing to do, no need to mix up everything else and get everyone unable to type under BeOS.

That's an overstatement. ;)

You were annoyed by ctrl and alt being swapped wrt to Windows, and that's ok, but it only affects power users that use keyboard shortcuts at all. Changing the meaning of AltGr basically prevents reaching 1/3 of the characters on an Azerty keyboard. People are going to be lost, and this will affect 2-finger typers as well as profesionnal 10-fingers-or-more ones.

Again, I don't intend to change the meaning of AltGr. But I do want to change the meaning of Left Alt.

AltGr is the level3 shift (or "option" in the current terminology). Alt is the command key. Ctrl is the control key.

These are the 3 mandatory keys to use a keyboard and they are always there when needed. Old macintosh keyboard don't have AltGr (even today), but they don't need it either : their azerty is slightly different (called French (Mac) in Haiku), and it uses alt+shift+key for the extra chars, placing them elsewhere on the keyboard. This is also the layout used on the amiga and similar to the azerty layout of other machines (Amstrad CPC...).

I'm on a Mac now. Both Opt keys act as AltGr here. Though yes, it seems the French layout is slightly different than that in Windows.

Now, there is an extra key, that happens to be on most modern Pc keyboards : the Win key. Despite being mapped to 'something' in the current keymaps, this key has absolutely no use as of now. As this key is available on *most* keyboards, but not *all*, you can't rely on it. So you can't make it the only option key available, nor the only command key : that would just make most BeOS apps shortcuts unuseable for some people.

For power-users, as you said. I don't think only they use shortcuts, but I do believe that the number of keyboards without either a Win, or a Commadn key is very very tiny.

It can't be assigned to WM actions like stack-and-tile, because these aren't even reachable with only the mouse. As we didn't find an use for this key, we mapped it in a way that could be useful to some people. In American keymap it is the level3 shift, actually not doing anything ; for others, the level 3 shift was already mapped to AltGr, so the left Win was mapped to level3, while the right Win was mapped to Option. This is the only choice that can be played with. Moving any of the other keys would prevent use of some part of Haiku for some people.

You're confusing me again. Right win was mapped to Command I think, not Option, because at the moment, Option == Level 3 Shift.

[pulkomandy]

You are mixing things up.

Ok, so : AltGr should always be the 'option' key, that is, level-3 shift. Alt is, in the default settings, a Command key. Coming from linux/windows, you may want to swap that with control. There is a button just for that in the Keymap preflet.

Let's admit you do that. You get :

• AltGr as the Option key : same as in Windows, acts as a level-3 shift
• Alt key as control key : unused except in terminal
• Both control key as Command key : trigger application shortcuts as in windows.
• Win key : doing different things, not particularly useful.

Now, if you happen to :

• Lack both win key (such keyboard exists) : you can still use Haiku
• Lack an AltGr or othewise have a single Alt key (may happen, but didn't saw much of these) : you can still use Haiku
• Have a single control key (Amiga and I believe Sun keyboards) : you can still use Haiku.

Yes, it is a trick. Yes, it is not the good way to solve it. Yes, it is a waste of both win keys. the proper fix is :

• First, recognize there are different keys doing different things : currently we have Control (ctrl), Command (Alt), Option (AltGr), and we don't have any modifier that maps to Win.
• Before introducing this new modifier (or compose or whatever), there is no need swapping the other keys around. Whatever you do, it will always feel illogical to someone.
• Once the win key are assigned a meaning and use, they will stop duplicating the function of other keys, which is not what they should do.

You are both telling us to :

• Forget about all keyboard legacy and ways of use from any operating system (having Alt and AltGr being different keys)
• Forget about the way BeOS did it
• Also use something that is different from other OS (Alt and AltGr doing the same thing)

and then you complain about users getting lost ? Or maybe you don't, but others will. It's confusing.

I'm not opposed to changes, there IS something wrong, but don't try to replace a workaround with another and fix the real problem : we lack a modifier constant or some other use for the Win key.

Swapping Alt and LWin will make you happy, but prevent someone else to trigger any keyboard shortcut : problem not solved. I don't care, as I have an LWin key (but no RWin) on this laptop.

Look in the keymap preflet :

• IBM Laptop : only one LWin key, no RWin
• Kinesis : no win-key at all (and this is not a 15 year old keyboard). At least 3 of Haiku devs use this one. With mmu_man Model M, this makes 4 angry devs.
• Typematrix : lacks RWin.

Your "solution" just doesn't fit for some of these. It's not that it wouldn't work on a regular keyboard, it's that it will not work on something else. You can't rely on these win keys being there, and that's why they are put to functions we can live without :

• duplicating other keys, or
• Level3 shift for keyboards that don't need it.

As these keys are useless, yes, you are allowed to complain and tell they should be used more. They need their own modifier keycode ; and they should be useable on their own. But they will not have a nessential function, as some people just can't use them. A compose key or an user-magic-shortcut configurable key can fit. A vital function like Command can't.

[rq]

Replying to pulkomandy:

You are mixing things up.

Ok, so : AltGr should always be the 'option' key, that is, level-3 shift. Alt is, in the default settings, a Command key. Coming from linux/windows, you may want to swap that with control. There is a button just for that in the Keymap preflet.

OK, agreed.

Let's admit you do that. You get :

• AltGr as the Option key : same as in Windows, acts as a level-3 shift
• Alt key as control key : unused except in terminal
• Both control key as Command key : trigger application shortcuts as in windows.
• Win key : doing different things, not particularly useful.

This part about Both Control keys being the same is not exactly correct. Actually, right now the layout is like this:

Physical key	Left Ctrl	Left Win	Left Alt	Right Alt/AltGr	Right Win	Menu	Right Ctrl
Default mapping, US keymap	CTRL	OPT	CMD	CMD	OPT	MENU	CTRL
Windows-like mapping, US keymap	CMD	OPT	CTRL	CTRL	OPT	MENU	CMD
Default mapping, French keymap	CTRL	OPT	CMD	OPT	empty	MENU	CTRL
Windows-like mapping, French keymap	CMD	OPT	CTRL	OPT	empty	MENU	CMD
Default mapping, Lithuanian keymap	CTRL	OPT	CMD	OPT	empty	MENU	CMD
Windows-like mapping, Lithuanian keymap	CMD	OPT	CTRL	OPT	empty	MENU	CTRL

You know, I just realised that not only Haiku's European layouts are different from US, but they are also inconsisten among themselves. That is, in your case both Control keys are indeed the same, but in my case, they are not. This fact is partly responsible for us not being able to reach at least some sort of an agreement. This should definately be fixed (along with empty assignments) in #6364.

I was actually going to propose French-like mapping as at least a temporary solution, and now apparently, it simply exists.

Now, if you happen to :

• Lack both win key (such keyboard exists) : you can still use Haiku

Keyboards like that are really rare. I have no real figures but I would consider them pretty much exotic.

• Lack an AltGr or othewise have a single Alt key (may happen, but didn't saw much of these) : you can still use Haiku

Like I said, this had happened on Macs previously, but apart from that, I can't remember seeing a keyboard like that either. They probably don't even exist, because AltGr has been in use on PC's forever.

• Have a single control key (Amiga and I believe Sun keyboards) : you can still use Haiku.

Bah, and I never noticed that Sun keyboards lack a second Control. Well, I haven't used them much either. But I never suggested to give both Control keys different functions anyway.

Yes, it is a trick. Yes, it is not the good way to solve it. Yes, it is a waste of both win keys.

the proper fix is :

• First, recognize there are different keys doing different things : currently we have Control (ctrl), Command (Alt), Option (AltGr), and we don't have any modifier that maps to Win.
• Before introducing this new modifier (or compose or whatever), there is no need swapping the other keys around. Whatever you do, it will always feel illogical to someone.
• Once the win key are assigned a meaning and use, they will stop duplicating the function of other keys, which is not what they should do.

You are both telling us to :

• Forget about all keyboard legacy and ways of use from any operating system (having Alt and AltGr being different keys)
• Forget about the way BeOS did it

I strongly suggest at least the latter. BeOS was made for BeBox which had its own keyboard but is now dead. RIP. Now we have PC keyboards and they have slightly different from those of BeBox.

• Also use something that is different from other OS (Alt and AltGr doing the same thing)

and then you complain about users getting lost ? Or maybe you don't, but others will. It's confusing.

I would love to:

• merge Cmd and Ctrl like it's done in Windows and Linux (give both functions to Ctrl key(s))
• leave the function of AltGr to AltGr

Then we would Left Alt and both Win keys free and we could have even two slots for functions. E.g., one (Win) could be used as system-wide Command key, and the other (Alt) as Mnemonic Access key or Compose or whatever else we may think is feasible.

I'm not opposed to changes, there IS something wrong, but don't try to replace a workaround with another and fix the real problem : we lack a modifier constant or some other use for the Win key.

Swapping Alt and LWin will make you happy, but prevent someone else to trigger any keyboard shortcut : problem not solved. I don't care, as I have an LWin key (but no RWin) on this laptop.

I see not having Cmd and Ctrl on the same key as a real problem too. ;) As you know, I'd rather merge Alt(=Cmd) with Ctrl and give both functions to Ctrl key(s). This doesn't involve Win-key at all. On the contrary, this would automatically make Left Alt and Right Win (or both Alt's on US keyboards) free to use.

Look in the keymap preflet :

• IBM Laptop : only one LWin key, no RWin
• Typematrix : lacks RWin.

My laptop doesn't have RWin too. But if both Win-keys had the same function (or had different functions that can be lived without), this wouldn't be a problem.

• Kinesis : no win-key at all (and this is not a 15 year old keyboard). At least 3 of Haiku devs use this one. With mmu_man Model M, this makes 4 angry devs.

Actually, I googled for Kinesis, and found out that their newer models ​have Win-keys. Also, Kinesis' description says that the keyboard allows for reprogramming keys, so I suspect that Kinesis may not be such a big deal in the end.

Regarding mmu_man, his keyboard is 15-years old. Then again, some special mapping could probably be created (if needed) for keyboards without Win-keys.

So in the end, this doesn't necessarily make even one angry dev. ;)

Your "solution" just doesn't fit for some of these. It's not that it wouldn't work on a regular keyboard, it's that it will not work on something else. You can't rely on these win keys being there, and that's why they are put to functions we can live without :

• duplicating other keys, or
• Level3 shift for keyboards that don't need it.

As these keys are useless, yes, you are allowed to complain and tell they should be used more. They need their own modifier keycode ; and they should be useable on their own. But they will not have a nessential function, as some people just can't use them. A compose key or an user-magic-shortcut configurable key can fit. A vital function like Command can't.

I wouldn't mind them to become OS-wide command keys, probably not even reported to applications. After all, making them reported later is much less headache than making them no longer reported at some point.

[anevilyak]

Replying to rq:

• Lack an AltGr or othewise have a single Alt key (may happen, but didn't saw much of these) : you can still use Haiku

Like I said, this had happened on Macs previously, but apart from that, I can't remember seeing a keyboard like that either. They probably don't even exist, because AltGr has been in use on PC's forever.

My Kinesis only has a single Alt and it's brand new.

I strongly suggest at least the latter. BeOS was made for BeBox which had its own keyboard but is now dead. RIP. Now we have PC keyboards and they have slightly different from those of BeBox.

Last I checked, the BeBox used a perfectly normal PC-style keyboard. At least mine didn't come with anything special.

I would love to:

• merge Cmd and Ctrl like it's done in Windows and Linux (give both functions to Ctrl key(s))

I would absolutely hate that because I find ctrl much more awkward to reach than alt on most standard layouts. Sorry, but "everybody else does it that way" is not a good argument.

[pulkomandy]

Ok, if your keyboard doesn't work like french, let's fix that first. Keeping in mind that "alt vs ctrl as command key" isn't going to change, there's an option for that. The fact that there is an option means we couldn't reach an agreement for 10 years of development, so we made it an user setting. Settings are something we try to avoid, so if this one is there, it means there is really a string demand from both sides.

As for separating left- and right- keys, the BeAPI is made in a way that allow apps :

• To check both of them (is control pressed)
• To check for left/right specifically

The former is the recommanded way, because of things I said above : you can't require a keyboard to have two keys for each.

Merging "control" and "command": I see no interest in doing that. You say it "frees" a key, but control is already free for use in applications. It creates conflicts in terminal (break [ctrl c] vs copy [alt c] ; sleep [ctrl z] vs undo [alt z] ; and so on) and violates the Be API (which says there is control, command, option). Adding an extra modifier is ok, removing one is not because some apps may be using it already. Reassigning some keyboard shortcuts is another discussion.

So here's the plan :

• Fix some european keymaps to behave like french
• Add an extra modifier code for win key ; or make it a compose
• Start to think about how different actions should be distributed around these keys.

Is that ok for you ?

[rq]

Replying to anevilyak:

My Kinesis only has a single Alt and it's brand new.

Oops, I forgot that. Now tell me: the four keys that reside in the top rows of the key blocks that happen to be under your thumbs - can you reassign them easily?

I strongly suggest at least the latter. BeOS was made for BeBox which had its own keyboard but is now dead. RIP. Now we have PC keyboards and they have slightly different from those of BeBox.

Last I checked, the BeBox used a perfectly normal PC-style keyboard. At least mine didn't come with anything special.

Really? I thought it had a Mac-style keybooard with Control, Option and Command keys, not the one with Control, Win and Alt...

I would love to:

• merge Cmd and Ctrl like it's done in Windows and Linux (give both functions to Ctrl key(s))

I would absolutely hate that because I find ctrl much more awkward to reach than alt on most standard layouts. Sorry, but "everybody else does it that way" is not a good argument.

I wouldn't mind the option to swap Ctrl and Alt, like it swaps Command and Control now. You could just use it and we would both be happy. ;)

Replying to pulkomandy:

Ok, if your keyboard doesn't work like french, let's fix that first.

Sure. At least we agree about that. :)

Merging "control" and "command": I see no interest in doing that. You say it "frees" a key, but control is already free for use in applications. It creates conflicts in terminal (break [ctrl c] vs copy [alt c] ; sleep [ctrl z] vs undo [alt z] ; and so on) and violates the Be API (which says there is control, command, option). Adding an extra modifier is ok, removing one is not because some apps may be using it already. Reassigning some keyboard shortcuts is another discussion.

I don't think there is an Undo function in Terminal, that's the point. There's Copy, Paste, New Tab, Close Tab and Quit. That's five shortcuts that would become inconsistent. I could live with that.

Though yeah, you can leave it like that in order not to break Be API for now. But I don't think it's useful in the long run, unless we find more ways to make use of Ctrl (Mnemonic Access?), though that would result in pointless inconsistency with two other operating systems, of which one has ~90% OS market share.

So here's the plan :

• Fix some european keymaps to behave like french
• Add an extra modifier code for win key ; or make it a compose
• Start to think about how different actions should be distributed around these keys.

Even just #1 would make me less grumpy. :) But other points are fine too, except I'd rather do #3 before going with #2.

[anevilyak]

Replying to rq:

Oops, I forgot that. Now tell me: the four keys that reside in the top rows of the key blocks that happen to be under your thumbs - can you reassign them easily?

Yes, but that doesn't mean I have any desire to.

Really? I thought it had a Mac-style keybooard with Control, Option and Command keys, not the one with Control, Win and Alt...

Mine at least came with a plain old AT keyboard.

I wouldn't mind the option to swap Ctrl and Alt, like it swaps Command and Control now. You could just use it and we would both be happy. ;)

Only if that also resulted in the same alt consistency with Terminal that I have now. I would *not* want to have to use Alt+C everywhere and then Ctrl+C in Terminal.

Though yeah, you can leave it like that in order not to break Be API for now. But I don't think it's useful in the long run, unless we find more ways to make use of Ctrl (Mnemonic Access?), though that would result in pointless inconsistency with two other operating systems, of which one has ~90% OS market share.

Again, I don't see the reasoning here. That argument could just as easily be applied to everything else Haiku does differently than the dominant OSes, at which point you may as well ask why use Haiku at all if you want everything to work exactly like it does in Windows.

[siarzhuk]

Replying to rq:

Replying to pulkomandy:

Ok, if your keyboard doesn't work like french, let's fix that first.

Sure. At least we agree about that. :)

By the way, current versions of Lithuanian keymaps were commited by me in request damoklas (Algirdas Buckus). So you should "thank" us for providing broken Lithuanian keymaps. ;-) Looks like some things were missed during mentioned keymaps design - so, please, check all again precisely.

[rq]

Replying to anevilyak:

Replying to rq:

Oops, I forgot that. Now tell me: the four keys that reside in the top rows of the key blocks that happen to be under your thumbs - can you reassign them easily?

Yes, but that doesn't mean I have any desire to.

And yet that means you can have one or two Alt, Control and Win keys (surely, not two of each at the same time though).

Really? I thought it had a Mac-style keybooard with Control, Option and Command keys, not the one with Control, Win and Alt...

Mine at least came with a plain old AT keyboard.

OK, I guess I confused NeXT and BeBox. The former seems to have had all peripherals included in the package. Maybe BeBox did not...

I wouldn't mind the option to swap Ctrl and Alt, like it swaps Command and Control now. You could just use it and we would both be happy. ;)

Only if that also resulted in the same alt consistency with Terminal that I have now. I would *not* want to have to use Alt+C everywhere and then Ctrl+C in Terminal.

Of course. But in Terminal, Alt+C would send SIGTERM to the application running in it.

Though yeah, you can leave it like that in order not to break Be API for now. But I don't think it's useful in the long run, unless we find more ways to make use of Ctrl (Mnemonic Access?), though that would result in pointless inconsistency with two other operating systems, of which one has ~90% OS market share.

Again, I don't see the reasoning here. That argument could just as easily be applied to everything else Haiku does differently than the dominant OSes, at which point you may as well ask why use Haiku at all if you want everything to work exactly like it does in Windows.

I tend to differentiate differences that I see as features from the ones I see as just differences for their own sake, and I'm not fond of the latter. That's surely subjective, but I'm not a robot. :) I like your ergonomic concerns, for example (that Alt is easier for you to reach), but I don't like the "it was in BeOS this way, so it's carved in stone" part of the argument. I also don't enjoy pulkomandy's position, because I see this "we really need those five keyboard shortcuts for Terminal, hence we need a separate key" argument as weak. In my opinion, I could live (and I do live!) with that inconsistency in one app (or rather one type of apps) if this would give me a key I could purposely use in all other applications.

OTOH pulkomandy is right: Control can already be used by applications. Maybe just don't like the fact (because I see no purpose for it) that the same functions are assigned to different keys in different operating systems.

Replying to siarzhuk:

I "thank" you for providing broken Lithuanian keymaps. ;)

Actually, I was going to improve them a little anyway, but just haven't gotten to that yet. What's the best/easiest way to do that, BTW?

[siarzhuk]

Replying to rq:

Actually, I was going to improve them a little anyway, but just haven't gotten to that yet. What's the best/easiest way to do that, BTW?

​http://dev.haiku-os.org/browser/haiku/trunk/src/data/keymaps - get the source keymap file, fix it and attach fixed *.keymap to Trac.

[axeld]

Please let's not mix different topics into this ticket: there is the key mapping issue at one side (some keymaps are broken, some people prefer Windows like shortcuts), and the issue this ticket actually is about on the other (AltGr needs a separate modifier bit). This ticket is not the right place to discuss the former.

So FWIW, I completely agree with pulkomandy :-)

[rq]

The thing is that AltGr doesn't probably really need a separate keycode.

Though OTOH, maybe it does. But in that case I would suggest to replace OPT-layer in the keymaps with AltGr-layer, so that we don't have a yet another layer in keymaps, but OPT is freed for use.

Hope this doesn't sound like bikeshedding... :)

[rq]

Back on track: Can we perhaps rename this bug to actually get a separate keycode for Win-keys, instead of splitting Alt and AltGr (they are already split functionally)?

Pulkomandy?

[jscipione]

This one is too hot for me, so I am relinquishing ownership.

[pulkomandy]

(In #6364) Lithuanian was the only keymap with misplaced left ctrl and this was fixed in #8553. The remaining problems are all because of lacking a separate altgr keycode which is already tracked in #6442.