I’d like to suggest introducing an option for truly Windows-compatible level3 chooser. We usually think that RightAlt is used on Windows for level 3, but the whole truth is that on Windows RightAlt is equivalent to Ctrl+Alt. In particular LCtrl+LAlt can be used to access national characters. That means, although with some difficulty, level 3 can be selected with either hand. This is important for some touch typists. This may seem abstract, but I’m actually trying to convince a particular person to use Linux, but she responds, she cannot use Linux, since the Polish keyboard works different than on Windows and she sometimes has to use a Windows computer. So to avoid confusion she will use Windows also at home. Since the Ctrl+Alt combination is rather useful in X, I propose to map only LCtrl+LAlt to Level3 and not other Ctrl+Alt combinations, in particular RCtrl+LAlt nor (if possible) RCtrl+RAlt. That probably means that RAlt should be { type[Group1]="PC_CONTROL_LEVEL2", symbols[Group1]= [ ISO_Level3_Shift, Alt_R ] }, while LAlt should be { type[Group1]="PC_LCONTROL_LEVEL2", symbols[Group1]= [ Alt_L, ISO_Level3_Shift ] }. I have tried to implement something along these lines but failed miserably. But maybe providing this kind of compatibility is worth the trouble.
Do you realize that all shortcuts using LCtrl+LAlt would disappear? Even if we implement that request, I would object against making that default behavior of level3(ralt) - it might break existing configs
(In reply to comment #1) > Do you realize that all shortcuts using LCtrl+LAlt would disappear? Sure thing. But it seems some users are used to the Windows behaviour, so we should provide a compatibility option for them. These people do not expect LCtr+LAlt to invoke any shortcuts. I think that keeping these shortcuts available via RCtr+RAlt is a reasonable trade off. > Even if we implement that request, I would object against making that default > behavior of level3(ralt) - it might break existing configs Definitely. I wouldn’t suggest such a thing. level3(ralt) has to remain as it is. The new option could be perhaps called level3(mswin).
ok, talking about level3(mswin) - what was your failure with that code you shown? It looks generally correct.
Created attachment 46794 [details] [review] unsuccessful attempt at a Windows compatible l3 switch I'm attaching my attempt at the definition. A success is that for RAlt xev reports the keysym ISO_Level3_Shift and for Ctrl+RAlt it reports Alt_R. But these keys stopped to work as modifiers. :-( In the case of LAlt+LCtr or LCtr+LAlt it is even worse: xev just reports Alt_L and Control_L and they work as previously. I tried to decorate this definition with virtual_modifiers and modifier_map, but frankly I'm doing this at random, for somehow I can't grasp the real meaning of these declarations. I do feel somewhat ashamed for myself. :-) I would be very thankful for any help. For complete symmetry (any)Ctrl+RAlt should be equivalent to RAlt+(any)Ctrl, but I do not see how that could be achieved.
When you run 'xkbcomp -a :0 -', you can see in the comments in the type section how virtual modifiers affect the real modifiers. This might help to resolve your problems. But there is another one: If the left Alt and Control keys are supposed to work like now when pressed without the other, they must still set the Alt and Control modifier. But once a modifier is set, XKB does not allow to reset it without releasing the key that set it. Therefore, whatever we do, Alt and Control together will at least set Alt or Control, maybe both, and maybe an additional modifier used to select Level 3. Even when we manage to access the third level, the Alt and Control modifier will confuse applications. There are two ways out: - Create a new type that uses on Control and Alt for lookup (thus "consuming" them, in XKB terminology), and "preserves" neither when the third level is accessed. The existing CTRL+ALT type is almost there, but it does not preserve Control and Alt when they are used by themselves (which is a bug, I think). Unfortunately, not all applications correctly handle consumed modifiers. - Use Redirect actions to remove the unwanted modifier from the keyboard event that is sent. Note that the server modifier status is not affected, and I am under the impression that some recent GTK software actually use the latter sometimes. Both approaches have one major flaw in common: They are very invasive. One must touch every single layout. And one must keep the previous behaviour for people that do not want the Windows convention, so basically each layout will be duplicated.
Hi. I'm a professional coder who has been affected by this for a long time. I'm glad someone brought this up and I would like to help. What I'm looking for when typing is symmetry - to be able to have all possible modifier keys on both sides of the keyboard. This includes Shift, Alt, Control and 'Third level chooser'. This is very important for efficient typing. The truth is that both Windows and Linux have suboptimal solutions for this problem. I'm on a Swedish keyboard, which has Ctrl and Alt on the left and Ctrl and 'Alt Gr' on the right. It uses third level keys extensively, especially for programming keys. Such keys include '{}[]\@$|', all pretty important for coding. The keys to type these are both on the left and right ( 2,7,8,9,0,hyphen and <> on US keyboards), so I need to enable the third level chooser with both left and right hands for efficient typing. With the standard keyboard layout I don't have an alt key on the right, so if I want to close a Dialog i need to use 'Left Alt' + 'c'. This I cannot do in a touch-typist way since both keys are on the same hand. What I do in Windows to fix this is to reprogram 'Alt Gr' to a normal 'Right Alt'. This way I have both Alt and Control on both sides and can perform Alt-c type combinations as well as choose third level - for instance 'Left Ctrl'+'Left Alt'+2, which produces the at sign ('@'). On the left side i can also use Ctrl+Alt for third level chooser, for instance 'Left Ctrl'+'Left Alt'+8 for open bracket ('['), or 'Left Ctrl'+'Left Alt'+9 for open curly brace ('{'). So all in all, if I on Windows reprogram 'Alt Gr' to 'Right Alt' everything turns symmetric and I am happy. This is due to the fact that 'Ctrl'+'Alt' is third level chooser. On Linux this approach does not work since there is no way of getting a symmetric third level chooser that doesn't conflict with other usages. Normal AltGr key: I lose right alt as mentioned above Any Alt key: conflicts with normal 'Alt+C' type usage Any Win key: Would be fine if most keyboards did in fact have two win keys, which they don't. Also conflicts somewhat with Unity. Backslash: Only one key, not symmetric Caps lock: Only one key, not symmetric Enter on keypad: Only one key, not symmetric Left alt: Only one key, not symmetric Left win: Only one key, not symmetric Less/greater: Only one key, not symmetric Menu: Only one key, not symmetric Right Alt: Only one key, not symmetric Right Ctrl: Only one key, not symmetric Right Win: Only one key, not symmetric So it looks like I'm out of luck in the current situation. It is simply hard to find a pair of physical keys to use as third level choosers. It seems like symmetry was not a top priority for keyboard designers, especially not on netbooks and other small form factors. Due to the lack of physical keys I think that Ctrl+Alt is a good choice. Those keys exist on most keyboards and also on both sides. But if that is problematic due to backwards compatibility you could really choose any symmetric key combination, perhaps Shift+Ctrl? To summarize, my ideal solution would be to have one tick box that said 'reprogram Alt Gr to become normal right alt and enable Ctrl+Alt for third level chooser'. Ctrl+Alt could optionally be replaced with some other combination like Shift+Ctrl, as long as it can be typed with any hand. I am more than happy to help code this if and when we agree. But first I would like to ask how much we risk to break with using Ctrl+Alt. In my mind it is already a quite unusual stroke. I know that it is used for workspace switching so it must already be considered somewhat 'system-level', which would make it a valid choice, wouldn't it?
I believe one possible solution would be to provide alternative definitions for THREE_LEVEL, FOUR_LEVEL, and similar types. For example: type "THREE_LEVEL" { modifiers= Shift+LevelThree+Alt+Control; map[Shift]= Level2; map[LevelThree]= Level3; map[Shift+LevelThree]= Level3; preserve[Shift+LevelThree]= Shift; map[Control+Shift]= Level2; map[Control+LevelThree]= Level3; map[Control+Shift+LevelThree]= Level3; preserve[Control]= Control; preserve[Control+Shift]= Control; preserve[Control+LevelThree]= Control; preserve[Control+Shift+LevelThree]= Shift+Control; map[Alt+Shift]= Level2; map[Alt+LevelThree]= Level3; map[Alt+Shift+LevelThree]= Level3; preserve[Alt]= Alt; preserve[Alt+Shift]= Alt; preserve[Alt+LevelThree]= Alt; preserve[Alt+Shift+LevelThree]= Shift+Alt; map[Alt+Control]= Level3; map[Alt+Control+Shift]= Level3; map[Alt+Control+LevelThree]= Level3; map[Alt+Control+Shift+LevelThree]= Level3; preserve[Alt+Control+Shift]= Shift; preserve[Alt+Control+LevelThree]= Alt+Control; preserve[Alt+Control+Shift+LevelThree]= Shift+Alt+Control; level_name[Level1]= "Base"; level_name[Level2]= "Shift"; level_name[Level3]= "Level3"; }; which would override the default definitions, if requested. Currently, a similar approach is used to customize the interplay of Shift and Lock. This solution would pose no compatibility problems, and it would play nicely with existing definitions (this was one of my main concerns before). The solution above would probably not work with one application or another, but that would be a bug of those applications. Another idea is to use the compose mechanism, using something like this in ~/.XCompose: Ctrl Alt <e> : EuroSign This would require a small patch in libX11, to mask out Ctrl and Alt in the generated keysym. This is simple, I could write such a patch, if there is interest (it would change existing behaviour, but I cannot imagine that anyone relies on it). Disadvantage of this solution is that it is implemented in personal setup rather than in system-wide files, and that it only works if XIM is used. Actually, both approaches could be combined. Maybe some application that do not understand that Ctrl and Alt can be used to select levels will at least understand XIM.
(In reply to comment #1) > Do you realize that all shortcuts using LCtrl+LAlt would disappear? This is a reason for implementing this in itself. Users do not expect to type their name and have the lock-screen come on, which certainly can happen if a user used to the Ctrl+Alt = AltGr binding uses a default Linux set-up. Conversely, we can already set other overrides that have keys act as level3 chooser, including LAlt on its own and LCtrl on its own, which also blocks many shortcuts (I would suggest more, and more frequently used, but I'm sure that varies from user to user). These are the shortcuts that are more likely to match those affected users are already used to. Note finally, that the request is that LCtrl+LAlt only be affected, RCtrl+LAlt or RCtrl+RAlt (when available on keyboards) would still give access to the shortcuts that this option would block. Since these shortcuts would be new functionality to the users affected, there's no downside of changing things users are familiar with; these users aren't familiar with said shortcuts at all. > Even if we implement that request, I would object against making that default > behavior of level3(ralt) - it might break existing configs I would certainly agree. It makes no sense to change the defaults for millions of Linux users to match what users of another OS are used to, all the more so when that OS was in turn implementing a kludge to deal with a failing of some keyboards (those without a level3 chooser) that people then got used to. I'm not even sure if I'd choose the option now (I'm getting used to the AltGr use I'm forced into so I might opt to keep LCtrl+LAlt accessing the shortcuts it currently gives me), but it would have been a no-brainer choice for me some time ago. (And at least I know about AltGr and hence could figure out what to do, some users just think of Ctrl+Alt as the special-form-of-letter selector and would be at a greater loss). It would be a horrible default, IMO, but a great option.
Another use case for this Windows-compatible level3 chooser is when the X server is running on Windows itself. It's occasionally requested that the level3 shift be configurable to match Windows (e.g. https://cygwin.com/ml/cygwin-xfree/2015-02/msg00046.html)
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/issues/33.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.