| Summary: | Patch to map Control to the Win-keys | ||
|---|---|---|---|
| Product: | xkeyboard-config | Reporter: | Stephen Gildea <stepheng+freedesktop> |
| Component: | General | Assignee: | xkb |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | high | ||
| Version: | unspecified | ||
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
Patch to map Control to the Win-keys
Remove the Alt key mappings from altwin(ctrl_win) |
||
Created attachment 7760 [details] [review] Patch to map Control to the Win-keys thanks, committed. Is there a reason why this patch does modify Alt keys? This will cause trouble, e.g. many layouts map Alt_R to ISO_Level3_Shift. (In reply to comment #3) > Is there a reason why this patch does modify Alt keys? This will cause > trouble, e.g. many layouts map Alt_R to ISO_Level3_Shift. Oops, sorry I overlooked it. Yes, it looks like modifying ALT keys should not be there... (In reply to comment #3) There are two reasons why I think it does make sense to include setting the Alt keys in this option. Some of the layouts one might want to use this option with rely on generating Meta or Alt with the Windows-logo keys. Since I'm removing that, I need to ensure Alt is on the Alt keys. Second, the motivator for this layout option--having both Alt and Control conveniently close on each side of the keyboard--seems consistent and unifying enough to justify wrapping this as a single option. In particular, I do want to defeat mapping Alt_R to ISO_Level3_Shift, because a second Alt key is more useful for minimizing finger motion, Having made those points, I'll grant your point that maybe not everyone wants Alt keys. We could make two options out of this, one with and one without the Alt keys mappings. (Thank you for applying my patch so promptly!) By default, layouts do not modify Alt or Logo keys, except for Alt_R. If Logo keys are mapped to Alt or Meta, this is done through XKB options. I fail to see why resetting Alt_L and Alt_R does any good, but can easily see why it it troublesome ;) Stephen, can you please give examples of configuration which would be broken without resetting these keys? Created attachment 7779 [details] [review] Remove the Alt key mappings from altwin(ctrl_win) Denis is correct, and I do not need to modify the Alt keys. I had done some testing with XFree86 4.3, and there the U.S. Dvorak layout mapped Alt_R to ISO_Level3_Shift, with no way to undo that. I thought I needed to fix that here, but I now see that it was a bug in the old mappings. The current xkeyboard-config Dvorak does not touch Alt_R; instead you use a separate level3 option to say whether you want ISO_Level3_Shift and if so where (e.g., on Alt_R). With the clean separation between the basic layout, the altwin options, and the level3 options, each layout and option can be simpler and orthogonal, and they still combine nicely. I believe this is what Denis was arguing for in my patch. (I see some other layouts (that I don't use) still do include "level3(ralt_switch)". Since, as I found out, there is no way to undo this layout choice once made, I wonder if that isn't a bug. Perhaps it's a convenient default, in which case it seems to me there should be a "level3(ralt_alt)" option to explicitly undo it. (But I'm wandering from the topic; this discussion could carry on in a new bug report.)) I have attached a patch to my patch that removes the Alt key mappings from the ctrl_win logo key mappings. > With the clean separation between the basic layout, the > altwin options, and the level3 options, each layout and > option can be simpler and orthogonal, and they still > combine nicely. I believe this is what Denis was arguing > for in my patch. You are fully right :) > (I see some other layouts (that I don't use) still do > include "level3(ralt_switch)". Since, as I found out, > there is no way to undo this layout choice once made, I > wonder if that isn't a bug. Perhaps it's a convenient > default, in which case it seems to me there should be a > "level3(ralt_alt)" option to explicitly undo it. (But I'm > wandering from the topic; this discussion could carry on in > a new bug report.)) Yes, there is no clean way to undo some changes, this is why we try to only modify what is really necessary. Layouts include "level3(ralt_switch)" for convenience when they define keys with more than 2 levels, so that everything works out of the box. But indeed this can cause trouble, and maybe it would have been better to not include it, this is a very legitimate question. > I have attached a patch to my patch that removes the Alt > key mappings from the ctrl_win logo key mappings. Thanks. Lads, I am glad we got quick consensus here. I wish it would be that easy every time:) Thanks, the last patch is committed. |
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.
The XKB symbols mappings of the Alt and Windows-logo keys support many options for the Windows-logo keys: as Meta, Super, or Hyper. It's almost a complete list, but missing from it is the option I prefer: Control. I like mapping the Windows-logo keys as additional Control keys because having both Control and Alt keys nearer the center of the keyboard on each side means less reaching with my little fingers. The attached patch adds this feature. The gist of the patch is this new paragraph: partial modifier_keys xkb_symbols "ctrl_win" { key <LALT> { [ Alt_L ] }; key <RALT> { [ Alt_R ] }; key <LWIN> { [ Control_L ] }; key <RWIN> { [ Control_R ] }; modifier_map Control { <LWIN>, <RWIN> }; modifier_map Mod1 { Alt_L, Alt_R }; }; My patch is against symbols/altwin rev 1.8, shipped with xkeyboard-config 0.9 (aligned with Xorg 7.1.0).