Actually if you configure an app to be launched with CTRL (say thunar, for the example) only, and another to be launched with CTRL+A (say the terminal), and you type CTRL+A, you launch thunar THEN terminal. (but they are spawned in the same key combination...) The example I have given is pretty dumb, but some keys are in some systems used for many things, and it is useful. At least, I love it :) The example I want to take is the windows'one. Keyboard shortcuts of the desktop environment are based on the SUPER key: _ SUPER alone summon the equivalent of xfce4-popup-applicationsmenu _ SUPER+E starts the file browser (you could use thunar here) _ SUPER+L Lock the session _ SUPER..... It's pretty nice, because it allow to use all key combination not based on SUPER for other applications, giving something we could name a 'shortcut theme'* which give shortcuts easy to remember and avoid conflicts. I don't know any app which use a windows shortcut... But I know that it's not possible (at least easy) for user in this closed desktop environment to modify windows shortcuts. The fact is, when it is possible to modify and add some, conflicts can happen, because of the great variety of applications that we are able to add to our Linux distribution. If we take my first dumb example, CTRL+A is often used to select all items. If you assign CTRL to an application (by example, something to show a circle where your mouse is to enhance visibility of cursor) and want to select everything in an application, with CTRL+A, you make both things, and it could be not wanted. To finish this long report, I would say that it could be relatively easy to implement: 'just' call the application when keys are released, not pressed. The only problem I see now with this solution is to detect the FULL release of the shortcut. (else the problem will just be inverted, calling the application of the first key released in first and not the one of the first key pressed) To conclude: Thanks for this nice, customizable and light DE, and sorry for the long post. *: now as I think of it, keyboard theme could be an interesting feature... but it's not the point here.
Implementing this is easy (one line of code) and does not change the workflow that much, I would go for it. Jannis and Nick, any points against this?
I think we've had this discussion before and some of the cons i can remember was that it feels slow to wait for the release and it is also different from what's done normally (ie all gtk apps react on button press). The <super>-only care is not completely true either, because if you use the bindings as described in the first post and quickly press <super>-e both thunar and the menu are shown. Maybe we can improve that, so the "long" bindings is executed and menu is omitted.
If it matters, windows handles only <super> as a release and <super>-{l,e} do their work on button press.
I guess that if we handle Super on release, it makes sense to handle Control, Alt and Shift on release too. Do you both agree with that?
That's not a very good idea I think. It should be smarter to select events and not spawn two commands on the same key combination.
Sorry for the long laps of time, I didn't often look my mails those last times. [quote]I guess that if we handle Super on release, it makes sense to handle Control, Alt and Shift on release too. Do you both agree with that?[/quote] I agree. I think the easier way is to define "MOD" (modifiers, as opposite as "KEY" next on this message) keys, and make those keys react on release if no other key where pressed. In this solution, you will have 2 different behaviors, depending on if there where another key pressed or not (please keep in mind that it's only a quick idea, I don't know how you have implemented things): First case: user press a MOD user press another MOD (allow multiple MOD to be used) user press a KEY XFCE set a flag to disable calling the pure MOD binded app. (allow to cancel the call if user use a non-binded combination, by example in case the bind is used in another software. Avoid boring user can be interesting) XFCE start the binded application if there is one user press another KEY software start the binded application if there is one user release one of pressed MOD user release last pressed MOD XFCE look the flag: the flag is set, so do nothing XFCE unset the MOD flag end case Second case: user press a MOD user press another MOD user release a MOD user release the last MOD XFCE look the flag: the flag is not set, start the binded application end case Please keep in mind that I don't know internals of XFCE and I have wrote it in a few minutes, so I have probably miss some special cases.
Hello, I would like to add to this bug report that I have pretty much the same configuration Morel mentioned: SUPER alone summon the equivalent of xfce4-popup-applicationsmenu SUPER+E starts the file browser (you could use thunar here) The problem I experience is that after thunar fires up, the applications menu fires up as well.
I also have this problem, and I see that the bug report is 2.5 years old. If you aren't going to fix it, then please at least take the time to give us a pointer to the location in the code that handles shortcut processing so one of us can create a patch for it ourselves.
*** Bug 10845 has been marked as a duplicate of this bug. ***
*** Bug 10650 has been marked as a duplicate of this bug. ***
*** Bug 11434 has been marked as a duplicate of this bug. ***
*** Bug 10954 has been marked as a duplicate of this bug. ***
*** Bug 10794 has been marked as a duplicate of this bug. ***
Yes, please could you give us where this functionnality is handled? I would like to create a patch about this. Regards
I also experience this. <Super>-only prevents action assigned to <Super>+D.
I have developed a patch for XFCE to make Super-key behavior windows-like. 1. Invokes shortcuts via holding Super+<any key> (i.e. Super+D, Super+L, ...) 2. Invokes Super_L (also Super_R) shortcut on RELEASE of Super-key if no any other shortcut (Super+<any key>) was invoked. How can I submit it for review? P.S.: Sorry for bad english.
Created attachment 6422 Makes Super-key behavior windows-like This patch addresses a behavior of Super-key like when you press in combination with other keys, as well as for a single.
(In reply to BIG from comment #17) > Created attachment 6422 > Makes Super-key behavior windows-like > > This patch addresses a behavior of Super-key like when you press in > combination with other keys, as well as for a single. I would like to have this. Do I need to recompile everything? I'm on xubuntu 14.04 =x XFCE 4.12.0
(In reply to kafran from comment #18) > (In reply to BIG from comment #17) > > Created attachment 6422 > > Makes Super-key behavior windows-like > > > > This patch addresses a behavior of Super-key like when you press in > > combination with other keys, as well as for a single. > > I would like to have this. Do I need to recompile everything? I'm on xubuntu > 14.04 =x XFCE 4.12.0 You have to rebuild libxfce4kbd-private-2.so (or *-3, or maybe both).
(In reply to BIG from comment #19) > (In reply to kafran from comment #18) > > (In reply to BIG from comment #17) > > > Created attachment 6422 > > > Makes Super-key behavior windows-like > > > > > > This patch addresses a behavior of Super-key like when you press in > > > combination with other keys, as well as for a single. > > > > I would like to have this. Do I need to recompile everything? I'm on xubuntu > > 14.04 =x XFCE 4.12.0 > > You have to rebuild libxfce4kbd-private-2.so (or *-3, or maybe both). @BIG, Didn't worked here. Applied the patch, build and repack libxfce4ui on xubuntu 14.04 with XFCE 4.12.0 and didn't work. Well, at least <super> key is working on release now. But if I bind it alone to an app (open the aplication menu for example) I can't use it in a "combo" <super> + 1 to change to workspace 1 stops working, for example. If I don't use it alone, I can use it in "combos".
(In reply to kafran from comment #20) > (In reply to BIG from comment #19) > > (In reply to kafran from comment #18) > > > (In reply to BIG from comment #17) > > > > Created attachment 6422 > > > > Makes Super-key behavior windows-like > > > > > > > > This patch addresses a behavior of Super-key like when you press in > > > > combination with other keys, as well as for a single. > > > > > > I would like to have this. Do I need to recompile everything? I'm on xubuntu > > > 14.04 =x XFCE 4.12.0 > > > > You have to rebuild libxfce4kbd-private-2.so (or *-3, or maybe both). > > @BIG, > > Didn't worked here. Applied the patch, build and repack libxfce4ui on > xubuntu 14.04 with XFCE 4.12.0 and didn't work. Well, at least <super> key > is working on release now. But if I bind it alone to an app (open the > aplication menu for example) I can't use it in a "combo" <super> + 1 to > change to workspace 1 stops working, for example. If I don't use it alone, I > can use it in "combos". libxfce4ui - is not the library you should rebuild. You should rebuild libxfce4kbd-private-2.so or libxfce4kbd-private-3.so.
(In reply to BIG from comment #21) > (In reply to kafran from comment #20) > > (In reply to BIG from comment #19) > > > (In reply to kafran from comment #18) > > > > (In reply to BIG from comment #17) > > > > > Created attachment 6422 > > > > > Makes Super-key behavior windows-like > > > > > > > > > > This patch addresses a behavior of Super-key like when you press in > > > > > combination with other keys, as well as for a single. > > > > > > > > I would like to have this. Do I need to recompile everything? I'm on xubuntu > > > > 14.04 =x XFCE 4.12.0 > > > > > > You have to rebuild libxfce4kbd-private-2.so (or *-3, or maybe both). > > > > @BIG, > > > > Didn't worked here. Applied the patch, build and repack libxfce4ui on > > xubuntu 14.04 with XFCE 4.12.0 and didn't work. Well, at least <super> key > > is working on release now. But if I bind it alone to an app (open the > > aplication menu for example) I can't use it in a "combo" <super> + 1 to > > change to workspace 1 stops working, for example. If I don't use it alone, I > > can use it in "combos". > > libxfce4ui - is not the library you should rebuild. > You should rebuild libxfce4kbd-private-2.so or libxfce4kbd-private-3.so. I know. New tests, it seems like the shortcut set for on Keyboard Settings is conflicting with the ones on Window Manager Settings. If I use <super> key alone to open an app. And <super> + <an other key> to open an app, it works. But it doesn't work for window manager with <super> is set alone to an app. If I set <super> alone to a WM action, nothing happens.
(In reply to kafran from comment #22) > If I use <super> key alone to open an app. And <super> + <an other key> to > open an app, it works. Yep. This is exactly intended behaviour. > But it doesn't work for window manager with <super> is set alone to an app. > > If I set <super> alone to a WM action, nothing happens. Well, it really seems that my patch somehow conflicts with WM-settings. I will take a look at it. Thank you for the report!
(In reply to BIG from comment #23) > (In reply to kafran from comment #22) > > > If I use <super> key alone to open an app. And <super> + <an other key> to > > open an app, it works. > Yep. This is exactly intended behaviour. > > > But it doesn't work for window manager with <super> is set alone to an app. > > > > If I set <super> alone to a WM action, nothing happens. > Well, it really seems that my patch somehow conflicts with WM-settings. I > will take a look at it. Thank you for the report! @BIG, Could you replicate it? Thank you for the patch. This is exactly what I was looking for. Well, I'm too lazy to go back to the mainstream again >.< I will be waiting for the fix =). Att.
Yes, I have reproduced. I go when it is time and desire :)
By the way i have reverted my path and try user shortcust Super+Key in WM. I.e. Super+D for Show/Hide desktop, Super+1/2 to switch between Workspaces. And it does not work. But when i remove Super_L (standalone) from keyboard shortcuts it's works normal. Then i applied my patch again and test: still works fine. So i see this problem does not caused by my patch but it is bug in XFCE.! :)
*path=patch Sorry for terrible English again :)
(In reply to BIG from comment #26) > By the way i have reverted my path and try user shortcust Super+Key in WM. > I.e. Super+D for Show/Hide desktop, Super+1/2 to switch between Workspaces. > And it does not work. But when i remove Super_L (standalone) from keyboard > shortcuts it's works normal. Then i applied my patch again and test: still > works fine. > So i see this problem does not caused by my patch but it is bug in XFCE.! :) Hmmn. I will revert then and wait for XFCE's developers to fix this in the future. Thanks. (Don't worry, I'm not an english speaker as well)
I don't want this in the WM, that would break existing established workflows such as alt-tab for example.
BTW, if the whole idea behind this change is to use a single modifier as a shortcut, that seems wrong in the first place.
(In reply to Olivier Fourdan from comment #30) > BTW, if the whole idea behind this change is to use a single modifier as a > shortcut, that seems wrong in the first place. I always felt XFCE behaves weird about keyboard shortcuts. A lot of distros binds <super> key to whisker menu, for example, and this drives to strange behavior (the menu opening when you use <super> as a modifier to other command). What I feel it's as if the keyboard shortcut for apps conflicts with WM shortcuts, or they both understand <modifiers> keys differently. The <alt> modifier, for example, alone its standard for showing the menu in some apps and works well as a modifier, but, if you assign <alt> alone to open an app, <alt> as a modifier is dead. You can't use <alt> + <space> anymore, for example. It's like to different things controls the keyboard and they are not talking.
(In reply to kafran from comment #31) > (In reply to Olivier Fourdan from comment #30) > > BTW, if the whole idea behind this change is to use a single modifier as a > > shortcut, that seems wrong in the first place. > > I always felt XFCE behaves weird about keyboard shortcuts. A lot of distros > binds <super> key to whisker menu, for example, and this drives to strange > behavior (the menu opening when you use <super> as a modifier to other > command). Which is to be expected, becauset he Wisker menu will have a passible grab on the modifier, triggering any time the modifier is pressed. Which is exactly why I reckon using a single modifier as a shortcut is wrong, modifiers are, as their name implies, to modify the behavior of other keys. > > What I feel it's as if the keyboard shortcut for apps conflicts with WM > shortcuts, or they both understand <modifiers> keys differently. The <alt> > modifier, for example, alone its standard for showing the menu in some apps > and works well as a modifier, but, if you assign <alt> alone to open an app, > <alt> as a modifier is dead. You can't use <alt> + <space> anymore, for > example. Same thing, don't use Alt (a modifier) alone to open another app. > It's like to different things controls the keyboard and they are not talking. Every single application is free to have a passive grab on any key and react the way it wants.
(In reply to Olivier Fourdan from comment #32) > (In reply to kafran from comment #31) > > (In reply to Olivier Fourdan from comment #30) > > > BTW, if the whole idea behind this change is to use a single modifier as a > > > shortcut, that seems wrong in the first place. > > > > I always felt XFCE behaves weird about keyboard shortcuts. A lot of distros > > binds <super> key to whisker menu, for example, and this drives to strange > > behavior (the menu opening when you use <super> as a modifier to other > > command). > > Which is to be expected, becauset he Wisker menu will have a passible grab > on the modifier, triggering any time the modifier is pressed. Shouldn't this be on release, not on press? > > Which is exactly why I reckon using a single modifier as a shortcut is > wrong, modifiers are, as their name implies, to modify the behavior of other > keys. > > > > What I feel it's as if the keyboard shortcut for apps conflicts with WM > > shortcuts, or they both understand <modifiers> keys differently. The <alt> > > modifier, for example, alone its standard for showing the menu in some apps > > and works well as a modifier, but, if you assign <alt> alone to open an app, > > <alt> as a modifier is dead. You can't use <alt> + <space> anymore, for > > example. > > Same thing, don't use Alt (a modifier) alone to open another app. > > > It's like to different things controls the keyboard and they are not talking. > > Every single application is free to have a passive grab on any key and react > the way it wants.
(In reply to Olivier Fourdan from comment #29) > that would break existing established workflows such as alt-tab for example. I've just checked Alt+Tab with my patch - everything works fine, so no problem here. (In reply to Olivier Fourdan from comment #30) > BTW, if the whole idea behind this change is to use a single modifier as a > shortcut, that seems wrong in the first place. A millions of people (include me) every day use Windows shortcuts - Super_L(standalone) to launch/hide Start Menu, Super_L+Key to launch actions. And they finds this scheme very usefull. Of course, it's possible to make a checkbox in the settings for enable/disable this behavior. If support for such features opens up some other bugs - it is all fixable anyway. I know, this shortcuts looks like a minor problem, but a hundreds of such "small issues" are prevent millions of people switch from Windows to Linux fulltime.
(In reply to kafran from comment #33) > (In reply to Olivier Fourdan from comment #32) > > Which is to be expected, because the Whisker menu will have a passible grab > > on the modifier, triggering any time the modifier is pressed. > > Shouldn't this be on release, not on press? That wouldn't make much difference, you'd get the menu open on the key release (instead of key press) while defining another shortcuts using the same modifier. There is no centralized shortcut management in X11, every app is free to grab keys (including modifiers) and do whatever they want with them, so there is no real "fix" for this, triggering actions on key press or key release doesn't change that problem.
(In reply to Olivier Fourdan from comment #35) > (In reply to kafran from comment #33) > > (In reply to Olivier Fourdan from comment #32) > > > Which is to be expected, because the Whisker menu will have a passible grab > > > on the modifier, triggering any time the modifier is pressed. > > > > Shouldn't this be on release, not on press? > > That wouldn't make much difference, you'd get the menu open on the key > release (instead of key press) while defining another shortcuts using the > same modifier. > > There is no centralized shortcut management in X11, every app is free to > grab keys (including modifiers) and do whatever they want with them, so > there is no real "fix" for this, triggering actions on key press or key > release doesn't change that problem. Well... ok then. I'm not a developer, I don't know how this works behind the scene. I'm just a desktop user who likes XFCE because I can use it the way I like, at least most things as I like. I like the way gnome-shell behaves about keyboard shortcut, but I don't like gnome-shell. If we can't have that way of handle keyboard in XFCE, no problem. I will forget about it. I just whish things were more keyboard driven, as gnome-shell.
This is always a hot topic between XFCE users. Well... here is another workaround: https://jimdean.id.au/2016/04/20/using-the-super-key-in-xfce/ I do not think this is a XFCE bug, but for sure it is not a expected behave by most of users. I really hope this behave changes in the future.
Yeah... xcape is well known crutch for this problem. As for me i didn't like such dirty hacks so i prefered to develop a patch for XFCE. Maybe i will create project on GitHub to host my patches.
*** Bug 12743 has been marked as a duplicate of this bug. ***
(In reply to Olivier Fourdan from comment #35) > (In reply to kafran from comment #33) > > (In reply to Olivier Fourdan from comment #32) > > > Which is to be expected, because the Whisker menu will have a passible grab > > > on the modifier, triggering any time the modifier is pressed. > > > > Shouldn't this be on release, not on press? > > That wouldn't make much difference, you'd get the menu open on the key > release (instead of key press) while defining another shortcuts using the > same modifier. > So the desired behavior is achieved by breaking down key combinations into presses and releases. Super+E is actually Super press + E press. Super (standalone) is actually Super press + Super release, where any keys in between break the combination.
> So the desired behavior is achieved by breaking down key combinations into > presses and releases. Super+E is actually Super press + E press. Super > (standalone) is actually Super press + Super release, where any keys in > between break the combination. Yes. However, if you want to emulate 100% of the capabilities of Windows, there's a few other cases that may not be handled with simply tracking the press/release of each key. For example, The following sequence in Windows: Super press -> E press -> E release -> R press -> R release -> Super release will invoke the shortcuts for both Super+E and Super+R, even though Super was not released and repressed between pressing E and R. I'm no coder and don't know how the underlying keyboard system works, but perhaps something like this: when.keypress ($key) { if ($SUPERisdepressed = 1) then do SUPERand[$key]function if ($CTRLisdepressed = 1) then do CTRLand[$key]function if ($ALTisdepressed = 1) then do ALTand[$key]function else passkeytoprogram($key) } But that's probably horrible and inefficient with whatever keyboard interfaces are present. The basic idea is that instead of triggering on a specific pattern of presses and releases that includes the modifier keys, keep track of which modifiers are pressed at any given time, so that it doesn't matter which order you press the modifiers in, or whether the modifier is held down during multiple keycombos.
Hello there. Maybe someone can make patch to change other mod-keys (Ctrl, Alt, Shift) to work on release? I'm working on Kali Linux xfce 2016.2 and this issue with shortcuts gives me headache...
I also think that this is a missing feature and I would love to see it in Xfce. (In reply to Olivier Fourdan from comment #32) > Which is exactly why I reckon using a single modifier as a shortcut is > wrong, modifiers are, as their name implies, to modify the behavior of other > keys. I don't think that it matters whether using only a modifier key as a shortcut seems wrong on a superficial level or not. While not allowing this might look like a senseful design decision on a purely theoretical level, there are clearly many people who would like to use this feature and have used it productively outside of Xfce for a long time. I would argue that, at the end of the day, the DE is there to provide users with a good working environment and that this is is more important. (In reply to Olivier Fourdan from comment #35) > That wouldn't make much difference, you'd get the menu open on the key > release (instead of key press) while defining another shortcuts using the > same modifier. > > There is no centralized shortcut management in X11, every app is free to > grab keys (including modifiers) and do whatever they want with them, so > there is no real "fix" for this, triggering actions on key press or key > release doesn't change that problem. As far as I can see this doesn't really matter, because the desktop environment is responsible for keyboard shortcuts. There should not be a problem in exercising some control over which key presses are registered as shortcuts and which aren't. The portion of Xfce that is responsible for keyboard shortcuts then becomes this "centralized shortcut management". Some approaches have already been stated. Here is what I thought of: * Shortcuts for single modifier keys (e.g. only Super, or only Alt) are executed on key release. * Shortcuts for single or multiple modifier keys in combination with a single normal key (e.g. Super+A, or Alt+F1) are executed on key press for the normal key. You could query for the normal key first, and only then look if the necessary modifier key is held during the press). * Shortcuts for single or multiple modifier keys in combination with multiple normal keys (e.g. Super+Left+Up) are executed on key press for "the last" normal key that is pressed. This essentially follows the same rules as the previous situation; you look for one of the normal keys and then consecutively check if all necessary other keys (including the modifier key) are held during the press. The last point might sound strange at first, but it would enable more intuitive controls for window tiling. For example, you could use Super+Up+Right to tile a window to the upper right corner.
I think this should work as follows: if Super is pressed and no other key is pressed afterward in 0.2s bring menu, otherwise treat it as someone will press another key with Super
I think this should work as follows: if Super is pressed and no other key is pressed afterward in 0.2s bring menu, otherwise treat it as someone will press another key with Super Also to note that this bug was assigned 2015-03-10 12:01:22 CET and it's importance is Low minor I think it should be reassigned as a current asignee haven't solved it in a year and change importance - to have a Windows like shortcut behavior (which is same as Gnome 3 as far as I remember) is not something should have Low minor importance but rather as "Medium".
*** Bug 13476 has been marked as a duplicate of this bug. ***
+1. Any updates on this?
I've updated the patch a bit, but for unknown reason I can not add it to the comment :(
This, a million times this, I was actually loosing my mind today, as a new Linux user, recently moved from Windows, I want my migration to be gradual and find these kinds of shortcomings a bit tedious. Can its priority not be changed at all ? It definitely is something wrong with how shortcuts are handled, there is also a patch. Please guys, fix this, it is 7 years old already.
@BIG do you have it somewhere, such as a github gist or a paste bin ? I would like to try it myself.
(In reply to istoica from comment #50) > @BIG do you have it somewhere, such as a github gist or a paste bin ? I > would like to try it myself. http://termbin.com/s6cz
@BIG, I'm interested in tackling this issue once and for all, please attach your latest patch so I can review it (your last link is 404ing). @Everybody else, there is a workaround for super work as a shortcut alone and as a modifier: https://xfce.space/en/2017/12/xfce-and-the-super-key/
Personnally, I tend to believe that nothing should happen on keydown of modifiers. A flag should be set when a plain key is used in addition, so that we know on release whether the modifier has been consumed, or deserves a consideration of its own ; we don't need to handle repeat on those anyway, so I don't see the point of doing otherwise Now, and this is the real point of my post, not everyone seems to realize how paramount this bug is. I know at least one entire R&D (batmaid.com) who have opted for Windows because of that very bug (and the non-usability of Gnome and lack of stability of KDE) : basically, standard window-tiling does not work with XFCE because of that, period ; or, that's the way they perceived it; they did not even go down to this hard-to-find bug report. They are now a ten-guys team and growing. and I am sure hundreds have left at least XFCE just because of that silly sandstone. We could just as well break Ctrl+F4, Ctrl+C and Ctrl+V, just to marginalize Linux a bit further ; I am sure Microsoft would love it. So, please stop discussing and fix it either way, plus include default customization for tiling : Super+Left, etc There are hundreds of users at stake, no kidding.
(In reply to Andre Miranda from comment #52) > @BIG, I'm interested in tackling this issue once and for all, please attach > your latest patch so I can review it (your last link is 404ing). https://yadi.sk/d/aVrFqOo23TG7D3
Created attachment 7635 Special super key handling Thanks BIG, I'm attaching to this bug your patch with my small improvements. It works very well, unfortunately xfwm4 bindings to Super+<Any Key> don't work anymore. My X11 knowledge is rather limited, but I think this is because xfsettingsd (via libxfce4ui) grabs the Super key thus any event concerning it is not passed to xfwm4. <rant mode> This "odd" behavior is one of the top complaints I receive from users new to Xfce and I myself am still very annoyed by it after all these years, devising key combinations with ctrl|shift|alt that don't conflict with apps is a PITA. The bottom line is: Super is not an ordinary modifier, anyone who has ever used another desktop environment (Gnome, KDE, Cinnamon, Windows...) expects Super alone to invoke an app launcher and a combination of it plus other keys to (usually) manage windows (show desktop, tiling, etc). </rant mode> @Olivier, I agree that handling keys on release would not help, in fact some use cases (e.g. alt+tab) would be affected. Is there any reason why xfwm4 has its own keys grabbing/handling? Historical or to not depend upon xfsettingsd? Since you're the X11 expert around and xfwm4's maintainer, do you happen to think of any way to get around the key grab limitation?
(In reply to Andre Miranda from comment #55) > > <rant mode> Please, this is bugzilla, not your favorite social network, rants do not belong to bugzilla. > This "odd" behavior is one of the top complaints I receive from users new to > Xfce and I myself am still very annoyed by it after all these years, > devising key combinations with ctrl|shift|alt that don't conflict with apps > is a PITA. The bottom line is: Super is not an ordinary modifier, anyone who > has ever used another desktop environment (Gnome, KDE, Cinnamon, Windows...) > expects Super alone to invoke an app launcher and a combination of it plus > other keys to (usually) manage windows (show desktop, tiling, etc). > </rant mode> The Super key has its own special treatment in mutter [1] (the “overlay” key), it's not a regular all-purpose key, not even in GNOME... There is no point in assigning Super for any special purpose in xfce. [1] https://gitlab.gnome.org/GNOME/mutter/blob/gnome-3-26/src/core/keybindings.c#L1844 > @Olivier, I agree that handling keys on release would not help, in fact some > use cases (e.g. alt+tab) would be affected. Is there any reason why xfwm4 > has its own keys grabbing/handling? Historical or to not depend upon > xfsettingsd? Since you're the X11 expert around and xfwm4's maintainer, do > you happen to think of any way to get around the key grab limitation? Keyboard events are routed to the window with keyboard input focus, meaning that the window manager must acquire a grab on its own if it ever wants to receive the keyboard events for its own use (i.e. its own keyboard shortcuts).
What we have here is dilemma: the technical side that claims super key is a only modifier key, but open to please users if it can be done cleanly, without hacks. On the other hand, many users coming from Windows (including myself) frown upon this limitation and refuse get used to new shortcuts. The ksuperkey author summarizes why he created it and provides some reasons why the problem exists in first place: https://blog.hanschen.org/2012/10/17/open-application-launcher-with-super-key/ It's interesting to learn that KDE3 had a special handling for super key but was removed "because it was a hack and quite broken". In the next days, I hope to survey other DEs to check if they have any special handling for super key and how they accomplish it. But don't hold your breath waiting for me, anyone is free to propose different solutions (BIG's patch works well, but once xfsettings grabs super key, xfwm4 will not receive any events for bindings that use it as modifier). Meanwhile users should consider ksuperkey (or xcape itself).
Here are the results of my little survey: Cinnamon: - Super alone (handled on release) opens menu - Super+arrows tiles windows - Super+d shows desktop I found that muffin uses XGrabKey and cinnamon-settings-daemon uses XIGrabKeycode But nothing about special handling for super key, neither XRecord usage https://github.com/linuxmint/muffin/blob/130d6f00d4fb7ba468d462bf1447e8c3bc6d9dd8/src/core/keybindings.c#L936 https://github.com/linuxmint/cinnamon-settings-daemon/blob/a74a48da2892abc93848d5b26c0c2adf68f7f67d/plugins/common/csd-keygrab.c#L76 Gnome: Similar behavior and code to cinnamon (obviously) Plasma: - Super alone (handled on release) opens menu - Super+arrows tiles windows (not the default, can be set) - Super+p opens display switcher No traces of XIGrabKeycode, XGrabKey or XRecord in kwin I couldn't find out what's their "settings-daemon" or the component responsible for global hotkeys Deepin: - Super alone (handled on release) opens menu - Super+left/right switches workspaces - Super+up/down maximizes/restores windows I'm almost certain it uses XRecord to handle modifiers on release: https://github.com/linuxdeepin/dde-daemon/blob/50c198f69cf8bbcf1a928d676acb0bf4c952b724/keybinding/shortcuts/xrecord_event_handler.go Mate: Super alone cannot be assigned to anything i3: Super ($mod) alone cannot be assigned to anything Unless XInput2's grab of Super does not prevent other windows to receive events of Super as modifier, I couldn't find the proper fix :'( XRecord is too much hack to be introduced in Xfce's code IMHO. For now, xcape -e 'Super_L=Control_L|Escape' on start up frees Super to be used as modifier, not an official fix, but a simple workaround.
*** Bug 14949 has been marked as a duplicate of this bug. ***
Perhaps Xfce would not need to wait that user released the keybinding, but it could use software way to release the keybinding so that it does not interfere the command to be executed. That could be optional, if there is some harm of it. Related problem with xdotool: https://bugs.launchpad.net/ubuntu/+source/xdotool/+bug/1812367
same? https://bugzilla.xfce.org/show_bug.cgi?id=12473
(In reply to bubi from comment #61) > same? https://bugzilla.xfce.org/show_bug.cgi?id=12473 Indeed. And this eager shortcut behavior causes not just harmless inconvenience but also systematic problems beyond xfce components. For example, assigning ctrl+shift (e.g. to keyboard switching) disables all the common shorcuts involving ctrl+shirt (e.g. restore closed window in Firefox/Chrome). When setting a shorcut, the user should be really only responsible for that particular combination of keystrokes instead of the whole exponential-sized set of enclosing combinations.
Fwiw, the problem with ctrl+shift+something shortcuts not working when ctrl+shift is used for keyboard layout switching is a bug of xorg, not xfce, see https://gitlab.freedesktop.org/xorg/xserver/issues/258 (migrated version) https://bugs.freedesktop.org/show_bug.cgi?id=865 (better readable) xorg handles keyboard layout switching, not xfce (xfce just sets the shortcuts of the xkb extension). The xkb extension standard would have to be extended and the x server extension changed accordingly for a fix. No one has done in the 15 years that bug stands. Anyhow I understand the original bug here - isolated press and release of super key (winkey) is a well defined act that does not hinder the use of super as a modifier (pressing additional key with super already pressed cancels the act of isolated press and release of super).
Maybe this can help with fixing the super key issue. https://github.com/hanschen/ksuperkey
(In reply to Jay Philips from comment #64) > Maybe this can help with fixing the super key issue. > https://github.com/hanschen/ksuperkey btw: ksuperkey is fork of xcape to use in KDE (basically, the change is only the default hotkey) and xcape is as workaroung mentioned many time above ;-)
I too would like to see the default handling of key shortcuts as described here. MS Windows does it that way. So does Cinnamon. Super alone --> invoke e.g. xfce4-popup-whiskermenu on key *release* Super+E --> invoke e.g. thunar on key *down* Thanks for the consideration and keep up the good work!
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.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.xfce.org/xfce/libxfce4ui/-/issues/1. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev