| Summary: | 2.18 breaks compose:ralt option on secondary russian layout (us,ru) | ||
|---|---|---|---|
| Product: | xkeyboard-config | Reporter: | Natrio <natrio> |
| Component: | General | Assignee: | xkb |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | pogonyshev, skrattaren |
| Version: | unspecified | ||
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=589776 | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
we need RALT for the 3rd level in order to access the Ruble character. See https://cgit.freedesktop.org/xkeyboard-config/commit/?id=85845be3a51f1ae790902b2b4c837d11382f50d8 (In reply to Sergey V. Udaltsov from comment #1) > we need RALT for the 3rd level in order to access the Ruble character. See > https://cgit.freedesktop.org/xkeyboard-config/commit/ > ?id=85845be3a51f1ae790902b2b4c837d11382f50d8 But this breaks Compose key for all the people who set it to right Alt! Including those who have no idea what is 3rd level and never use it. I could switch to rctrl no problem myself, but for thousands of users this is and will be a major frustration. You have a working setup (I had my for about 7 years), it may well have an entry for ruble sign, and SUDDENLY it's broken without any apparent reason. *And* you have no idea what's to blame (kudos to Gentoo Xorg maintainer, who suspected xkeyboard-config update). I can understand your anger, but the rule is that if we have any keysyms on level 3, we have to provide the switcher to that level, typically ralt. There are pros and cons to having (and not having) that rule. Luckily, ralt is not the only key that can be used as Compose. And please keep in mind that Windows users are used to have ralt+8 as ruble. The least surprize for them was to have it available here. No ideal solution. (In reply to Sergey V. Udaltsov from comment #3) > No ideal solution. Yes. There are right and wrong solutions. You can break one option for another one, like this hardcoded switch: > include "level3(ralt_switch)" or you can give people a choice. It is a philosophical question. Giving choice is definitely good, but there is another value: solution that works out of the box without extra tweaking, with expected behaviour. As I said, pros and cons. (In reply to Sergey V. Udaltsov from comment #5) > It is a philosophical question. Is the hardcoding a philosophical question? So, yes, in a sense. Hardcoded schemes is a philosofy of the Windows Way. However, I'm not talking about philosophy, but about replacing the optional setting >> compose:ralt by the non-optional hardcoded surrogate >> include "level3(ralt_switch)" Is the "level3" strongly requires hardcoding? As I explained earlier, if we introduce l3 in some variant, we require some l3 switcher in the same variant. I found it. $ grep -r 'lv3:' /usr/share/X11/xkb/rules/base.lst lv3:switch Right Ctrl lv3:menu_switch Menu lv3:win_switch Any Win key lv3:lwin_switch Left Win lv3:rwin_switch Right Win lv3:alt_switch Any Alt key lv3:lalt_switch Left Alt lv3:ralt_switch Right Alt lv3:ralt_switch_multikey Right Alt, Shift+Right Alt key is Compose lv3:ralt_alt Right Alt key never chooses 3rd level lv3:enter_switch Enter on keypad lv3:caps_switch Caps Lock lv3:bksl_switch Backslash lv3:lsgt_switch <Less/Greater> lv3:caps_switch_latch Caps Lock chooses 3rd level, acts as onetime lock when pressed together with another 3rd-level-chooser lv3:bksl_switch_latch Backslash chooses 3rd level, acts as onetime lock when pressed together with another 3rd-level-chooser lv3:lsgt_switch_latch <Less/Greater> chooses 3rd level, acts as onetime lock when pressed together with another 3rd-level-chooser https://cgit.freedesktop.org/xkeyboard-config/commit/symbols/us?id=50a7d5d6d5ef12289887336120c3c6cc6c0cb7ba - include "level3(ralt_switch)" + // do NOT hardcode this switch; use lv3:ralt_switch option instead! + //include "level3(ralt_switch)" So, level3 already WAS an option. "lv3:ralt_switch" was already available, we HAD a choice. But someone decided that the choice is a bad thing, good thing is the hardcode, but "works out of the box". Just except US layout: they were able to revert this patch. I gave it a thought. Ok. let it be so. There was a precedent. Too bad that we had to turn off. People used before Windows will be expected to enter his mark on the right Alt. For myself, still leave the line: include "level3 (ralt_switch)". This is useful, I often write the cost is not just a number and signed the currency in which this thing can be bought / sold. It is important. (In reply to Gleb Rostov from comment #10) > Too bad that we had to turn off. People used before Windows will be expected > to enter his mark on the right Alt. For myself, still leave the line: > include "level3 (ralt_switch)". This is useful, I often write the cost is > not just a number and signed the currency in which this thing can be bought > / sold. It is important. I'm not completely sure I understand you, but anybody including you can add `lv3:ralt_switch` to her/his XKB option and enter as much rouble signs as one likes. (In reply to Gleb Rostov from comment #10) > Too bad that we had to turn off. People used before Windows will be expected > to enter his mark on the right Alt. For myself, still leave the line: > include "level3 (ralt_switch)". This is useful, I often write the cost is > not just a number and signed the currency in which this thing can be bought > / sold. It is important. It's may be strange, but there is no any pre-hardcoded language switches, as some people expects to be. But you CAN configure it to Ctrl+Shift, Alt+Shift, CapsLock, etc. It also can be pre-configured by distro, but NOT unchangeable hardcoded "as expected". If you still need to set "grp:alt_shift_toggle" option, you always can also set "lv3:ralt_alt". And yes, it also may be pre-configured by distros, if the maintainers will want to support these expectations. Natrio,if I understand correctly, then here is your thesis: 1) you use a layout in Russian called WINKEYS, but want it to be complete copy of this very layout of Windows 2)you want to layout, which is a copy of the layout of Windows was inadequate for all because you are comfortable to use right alt other purposes 3) you advise a man accustomed to the standard windows-layout to use a different key, but do not want to use another free key for their own purposes. and you do not want to just remove the line at about Alt. it turns out that this is hypocrisy. and all you want to instill in place already used the standard opinion. I see only one way out - to make a full copy of the layout Windows, because so it was conceived. and you personally for their own purposes or to use a different layout on their own line to remove the hated you, or use a different key for their own purposes. (In reply to Gleb Rostov from comment #13) > and you do not want to just remove the line at about Alt. I can't JUST remove hardcoded line from /usr/share/* files without maintaining an alternative build of "xkeyboard-config" package. (In reply to Natrio from comment #14) > (In reply to Gleb Rostov from comment #13) > > and you do not want to just remove the line at about Alt. > I can't JUST remove hardcoded line from /usr/share/* files without > maintaining an alternative build of "xkeyboard-config" package. I detail everything described above. In addition, many layouts using the right alt for their own purposes. at the moment you want to change the standard for itself. if not so much like that used in the windows of alt to enter, so make convenient for your personal layout. but the layout WINKEYS should be what it is called and not someone's personal opinion. (In reply to Gleb Rostov from comment #15) > I detail everything described above. In addition, many layouts using the > right alt for their own purposes. at the moment you want to change the > standard for itself. if not so much like that used in the windows of alt to > enter, so make convenient for your personal layout. but the layout WINKEYS > should be what it is called and not someone's personal opinion. The layout is simply "ru", there is no way to choose it without "winkeys" or other specific variantns. The key swithes CAN be pre-defined normally, without hardcoding, but you want to do it by wrong way. winkeys variant was created long before Windows started using right Alt for rouble sign, and nobody promised `ru(winkeys)` to follow what Microsoft does. And I don't want my tried'n'true keyboard options (used for best part of 10 years) broken for newbies who are afraid to configure their keyboard themselves. The level3(ralt_switch) is configured as an option in rules. That should be sufficient to make it visible and usable in keyboard configuration tools. That's xkeyboard-config's work. Making it the default is distribution's work. There are different defaults that work for different people. The option must be configurable so different layouts work for different people. I traced down bug 98495 to this change. I'm not smart enough to understand all the pros and cons you discussed here, but is there a way I could have XKB work as before, with AltGR in Russian layout while pressed temporarily switching back to English layout? *** Bug 98495 has been marked as a duplicate of this bug. *** |
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.
On 2.17 .XCompose by option compose:ralt works fine on both primary US and secondary Russian layouts. My keyboard settings (without compose): --- /etc/X11/xorg.conf.d/99-keyboard.conf --- Section "InputClass" Identifier "Keyboard Defaults" MatchIsKeyboard "yes" Option "XkbLayout" "us, ru" Option "XkbOptions" "grp:caps_toggle, grp_led:scroll, terminate:ctrl_alt_bksp" EndSection ---------------------------------------------- In xmodmap's dump it looks like this. Before setting compose up: $ xmodmap -pke|grep 108 keycode 108 = Alt_R Meta_R Alt_R Meta_R Setting Right Alt compose: $ setxkbmap -option compose:ralt $ xmodmap -pke|grep 108 keycode 108 = Multi_key Multi_key Multi_key Multi_key On 2.18 compose:ralt works on US layout, on primary Russian (ru,us), but NOT on secondary Russian (us,ru). Dump before setting compose up: $ xmodmap -pke|grep 108 keycode 108 = Alt_R Meta_R ISO_Level3_Shift Setting Right Alt compose: $ setxkbmap -option compose:ralt $ xmodmap -pke|grep 108 keycode 108 = Multi_key Multi_key ISO_Level3_Shift As you see, for successful working compose on both layouts, we need "Multi_key" in words #1 and #3 , but since 2.18 it has "ISO_Level3_Shift" in word #3, regardless of assigning Compose to Right Alt. It can be workarounded by direct xmodmap command: $ xmodmap -e "keycode 108 = Multi_key Multi_key Multi_key Multi_key" and I found the new line in file /usr/share/X11/xkb/symbols/ru ("Windows layout" at beginning): ------- key <AB10> { [ period, comma ] }; key <BKSL> { [ backslash, slash ] }; + + include "level3(ralt_switch)" }; ------- Commenting out this line also fixes the problem.