There was a discussion in email regarding making C-A-Bksp optional. Participants: Julien Cristau, Peter Hutterer, Sergey Udaltsov Several quotes: --- PH: The "correct" solution would be to control zapping through xkb rulesets. Currently, the default symbols include the action Terminate_Server on Backspace. Removing this sym from the defaults and providing it through an xkb option allows C-A-B to be activated at runtime. It also means you can remap zapping to whatever key combo needed. --- SU: Would we please put it into the group "Miscellaneous compatibility options" in base.xml? I do not think it is worth separate group. Also, I would prefer to name it srvrkeys:??? (whatever you like), because srvrkeys:none is closely related. --- PH: srvrkeys:terminate_ctrl_alt_bksp seems like a pretty long name for that option, it'd be nice to be able to use something a bit shorter :/ Any suggestions? --- PH: one of the reasons for enabling dontzap is that some people trigger it accidentally. Ctrl-Alt-Backspace is quite similar to already used sequences in other programs. I think we will see other sequences that are different to zap the server in the future - at which point a separate group becomes worthwile. that's also the reason why I'd prefer the terminate:shortcut naming style, it is about as descriptive as you can get. having something like srvrkeys:terminate_ctrl_alt_bksp is even longer. --- SU: I am trying to think logically. If we disable C-A-B in srvrkeys:none, enabling it should be somewhere around, shouldn't it? I would love some consistent approach. If possible - without breaking compatibility. --- PH: btw. this makes me wonder if we should split the VT switching and mousekeys into a separate group and include it from pc by default. In which case no_srvr_keys would simply be an empty group, everything else would have srvr_control:default or so (Just thinking out aloud here)
Lads, if I missed something essential, please append.
Original patch: From: Julien Cristau <jcristau@debian.org> Date: Fri, 3 Apr 2009 18:16:02 +0200 Subject: [PATCH] Make Terminate_Server on ctrl+alt+bksp an option This disables zapping by default, it can be reenabled with 'setxkbmap -option terminate:ctrl_alt_bksp'. --- rules/base.o_s.part | 1 + rules/base.xml.in | 12 ++++++++++++ symbols/pc | 5 +---- symbols/terminate | 7 +++++++ 4 files changed, 21 insertions(+), 4 deletions(-) create mode 100644 symbols/terminate diff --git a/rules/base.o_s.part b/rules/base.o_s.part index c401790..a1cec13 100644 --- a/rules/base.o_s.part +++ b/rules/base.o_s.part @@ -97,4 +97,5 @@ shift:breaks_caps = +shift(breaks_caps) esperanto:qwerty = +epo(qwerty) esperanto:dvorak = +epo(dvorak) + terminate:ctrl_alt_bksp = +terminate(ctrl_alt_bksp) diff --git a/rules/base.xml.in b/rules/base.xml.in index 3f11c9a..ce60eaa 100644 --- a/rules/base.xml.in +++ b/rules/base.xml.in @@ -4921,5 +4921,17 @@ </configItem> </option> </group> + <group allowMultipleSelection="true"> + <configItem> + <name>terminate</name> + <_description>Key sequence to kill the X server</_description> + </configItem> + <option> + <configItem> + <name>terminate:ctrl_alt_bksp</name> + <_description>Control + Alt + Backspace</_description> + </configItem> + </option> + </group> </optionList> </xkbConfigRegistry> diff --git a/symbols/pc b/symbols/pc index 07472b8..9474df5 100644 --- a/symbols/pc +++ b/symbols/pc @@ -19,10 +19,7 @@ xkb_symbols "pc105" { include "pc(editing)" include "keypad(x11)" - key <BKSP> { - type="CTRL+ALT", - symbols[Group1]= [ BackSpace, Terminate_Server ] - }; + key <BKSP> { [ BackSpace ] }; key <TAB> { [ Tab, ISO_Left_Tab ] }; key <RTRN> { [ Return ] }; diff --git a/symbols/terminate b/symbols/terminate new file mode 100644 index 0000000..6108cae --- /dev/null +++ b/symbols/terminate @@ -0,0 +1,7 @@ +default partial modifier_keys +xkb_symbols "ctrl_alt_bksp" { + key <BKSP> { + type="CTRL+ALT", + symbols[Group1] = [ NoSymbol, Terminate_Server ] + }; +}; --
> this makes me wonder if we should split the VT switching and mousekeys into a separate group and include it from pc by default. In which case no_srvr_keys would simply be an empty group, everything else would have srvr_control:default or so (Just thinking out aloud here) We could use option group srvrkeys just for VT switching and mousekeys, also we'd move C-A-Bksp into new terminate group altogether. This would break compatibility, but would make new solution consistent. I wonder, if that kind of breakage would make people too upset. I do not think that many people explicitly use srvrkeys:none option, do you? That would be the only breakage point.
(In reply to comment #3) > > this makes me wonder if we should split the VT switching and mousekeys > into a separate group and include it from pc by default. In which case > no_srvr_keys would simply be an empty group, everything else would have > srvr_control:default or so (Just thinking out aloud here) > > We could use option group srvrkeys just for VT switching and mousekeys, also > we'd move C-A-Bksp into new terminate group altogether. This would break > compatibility, but would make new solution consistent. > > I wonder, if that kind of breakage would make people too upset. I do not think > that many people explicitly use srvrkeys:none option, do you? That would be the > only breakage point. Do we really break compatibility? if zapping is not in the default symbols, then srvrkeys:none still has the same effect - not enabling zapping. if we move zapping into a separate terminate group, then we only break if we have both srvrkeys:none and terminate:c-a-b - which can't exist in any current setup so there's no breakage here. for all other srvkeys:foo options (if there are any), we just replace those that have Terminate_Server on backspace with an include to terminate:c-a-b, and we thus get the same result. am I missing something here?
> Do we really break compatibility? If we remove C-A-Bksp handling from srvrkeys, yes we do. The person who'd use srvrkeys:none expects that shortcut to be disabled. But if we move it to terminate:* group, he might accidentaly kill X. Of course, if we keep the default zapping behavior. > if zapping is not in the default symbols, then srvrkeys:none still has the same > effect - not enabling zapping. Well, changing the default behaviour is even more questionable thing... I am not sure it is safe to disable zapping by default. Of course, hardware vendors and distromakers can do that, but in vanilla X I would prefer to keep it. Do you think that danger of accidentally pressing C-A-Bksp is so high? I actually never heard any complains from users...
(In reply to comment #5) > > Do we really break compatibility? > If we remove C-A-Bksp handling from srvrkeys, yes we do. The person who'd use > srvrkeys:none expects that shortcut to be disabled. But if we move it to > terminate:* group, he might accidentaly kill X. Of course, if we keep the > default zapping behavior. of course. I was assuming removing TS from the default symbols for the above comment to be true. > > if zapping is not in the default symbols, then srvrkeys:none still has the same > > effect - not enabling zapping. > Well, changing the default behaviour is even more questionable thing... I am > not sure it is safe to disable zapping by default. Of course, hardware vendors > and distromakers can do that, but in vanilla X I would prefer to keep it. Do > you think that danger of accidentally pressing C-A-Bksp is so high? I actually > never heard any complains from users... right now, we have DontZap enabled in X. and that's even worse IMO, because it requires a configuration change to enable it. removing it from the default map means we can revert the DontZap change and set this configuration at run-time. We already do so in Fedora, to a point that zapping is available in a plain X server and during gdm, but is then disabled after login (unless set otherwise). The main grief with zapping is simple: 1. It's a destructive key sequence that does not ask for verification and is (comparatively) poorly documented. "Destructive" because it kills your session and you cannot recover from it (unlike a VT switch). Of course, some applications make this less destructive by recovering to a before-crash state but this doesn't change the basic problem. From a UI design POV, this is about as wrong as it gets. 2. It's independent of the application. Because zapping happens before processing the event, applications can't even put a hook on it to verify it that's what the user really wants to do. One reason to only enable it if we really know the user wants it. 3. It's not obvious that this key zaps the server unless you are reasonably informed about the system you're running. A large number of users want to use the system to read email, etc. and not to read man pages about hidden key sequences. If they zap the server accidentally, this provides the illusion of an unstable system. 4. It is comparatively easy to zap accidentally. I can of course only provide one data point (myself) but I do it about once a week. Many of the gnome default shortcuts are on ctrl+alt, so all it takes is hitting backspace a bit too quick after e.g. maximising a window. Btw. it's very common to press keys before releasing previous keys, just check the event log in xev when you're typing. I cannot provide concrete numbers on how often this happens for other users.
> right now, we have DontZap enabled in X. and that's even worse IMO, because it > requires a configuration change to enable it. removing it from the default map > means we can revert the DontZap change and set this configuration at run-time. I see. You've nearly convinced me. > The main grief with zapping is simple: I agree with your points. It is really "last resort", as bad as it can be. > 4. It is comparatively easy to zap accidentally. I can of course only provide > one data point (myself) but I do it about once a week. Honestly, I never did it in my whole life. May be you should consider buying another keyboard?:) So, our conclusion so far: 1. We are totally dropping BKSP-related stuff from symbols/srvr_keys 2. We are creating symbols/terminate with two sections: "none" and "ctrl_alt_bksp". 3. Corresponding changes in rules/base and rules/base.xml Anything I am missing? I am going to post about that on planet.freedesktop.org, to give that solution more public visibility, ok?
(In reply to comment #7) > > 4. It is comparatively easy to zap accidentally. I can of course only provide > > one data point (myself) but I do it about once a week. > Honestly, I never did it in my whole life. May be you should consider buying > another keyboard?:) faster fingers would be better :) funnily enough, I'll still enable zapping on all servers anyway, so this patch has no effect on me personally. > So, our conclusion so far: > 1. We are totally dropping BKSP-related stuff from symbols/srvr_keys > 2. We are creating symbols/terminate with two sections: "none" and > "ctrl_alt_bksp". > 3. Corresponding changes in rules/base and rules/base.xml > > Anything I am missing? I think that should be it, and Julien's patch should cover most of that already too. > I am going to post about that on planet.freedesktop.org, to give that solution > more public visibility, ok? go for it.
Done! Thanks for your patch! Please check it works for you.
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.