#6442: AltGr should have a separate keycode -------------------------------+-------------------------------------------- Reporter: rq | Owner: pulkomandy Type: enhancement | Status: assigned Priority: normal | Milestone: R1 Component: Drivers/Keyboard | Version: Resolution: | Keywords: Blocked By: | Has a Patch: 0 Platform: All | Blocking: -------------------------------+-------------------------------------------- Comment (by rq): Replying to [comment:5 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. -- Ticket URL: <http://dev.haiku-os.org/ticket/6442#comment:6> Haiku <http://dev.haiku-os.org> Haiku - the operating system.