In reality 3 bugs, but filling out more than one is annoying (and they work worse in combination): 1. If you want to assign an already used shortcut to another action it tells you that the shortcut is already assigned but not which one. 2. While you assign a new shortcut to a action you can't use the keyboard in any other way. Maybe only grab the keyboard input if the window is selected? Would work around the following: - If the dialog box pops up telling you that the shortcut is already assigned, you still have no keyboard control and thus can't use <TAB> or <Enter>. - The window which asks for the new shortcut can be hidden by another window and it grabs the input while you are on another workspace without any visual notice that it exists. (Makes for some good pranks) 3. You can't scroll in the action list while you are asked for a new shortcut. This restricts how to operate the dialog without necessity. For example I wanted to find a usable shortcut while the dialog was open but was forced to close it because I couldn't scroll.
One bug per report, please...
(In reply to comment #1) > One bug per report, please... They work in combination. Let's rephrase it: setting keyboard shortcuts is user unfriendly.
(In reply to comment #2) > (In reply to comment #1) > > One bug per report, please... > > They work in combination. > > Let's rephrase it: setting keyboard shortcuts is user unfriendly. Don't wanted to be rude, sorry about that. My first sentence in the bugreport was not really helpful.
Yes, when you write something that amounts to, "I know this is more than one bug, but I'm too lazy to file more than one," it makes me kinda think, "well maybe I'm too lazy to help you." Anyhow: (In reply to comment #0) > > 1. If you want to assign an already used shortcut to another action it tells > you that the shortcut is already assigned but not which one. Known deficiency. Jannis, I feel like you said there was a technical reason for this; even then, we should try to fix this at some point anyway. > 2. While you assign a new shortcut to a action you can't use the keyboard in > any other way. Maybe only grab the keyboard input if the window is selected? Not sure that's possible, but... > Would work around the following: > > - If the dialog box pops up telling you that the shortcut is already assigned, > you still have no keyboard control and thus can't use <TAB> or <Enter>. That's a separate bug. The dialog should drop its kbd grab in this case, before displaying the error dialog. > - The window which asks for the new shortcut can be hidden by another window > and it grabs the input while you are on another workspace without any visual > notice that it exists. (Makes for some good pranks) How would you trigger this? How is it possible to bring up this dialog (which triggers the grab) while you're on a different workspace? > 3. You can't scroll in the action list while you are asked for a new shortcut. > This restricts how to operate the dialog without necessity. For example I > wanted to find a usable shortcut while the dialog was open but was forced to > close it because I couldn't scroll. There's no way around this. Keyboard grabs are X-server-global; you can't restrict them to when a specific window has focus (if you could, there'd be really no point to having them at all in that use case). It's possible to use a per-client (application) grab, but that won't work either because it allows other bound shortcuts to still work. Basically there's no way of saying "give me any and all key presses" without grabbing all keyboard input entirely. I suppose it's possible to work on window focus; if you use the mouse to switch to another window, perhaps we could drop the grab, but then reacquiring the grab when the shortcut window gets focus again (especially if it gets focus via one of the WM's keyboard shortcuts) can be unreliable.
> (In reply to comment #0) > > > > 1. If you want to assign an already used shortcut to another action it tells > > you that the shortcut is already assigned but not which one. > > Known deficiency. Jannis, I feel like you said there was a technical reason > for this; even then, we should try to fix this at some point anyway. The problem is that the xfwm4 shortcuts have two names: one for displaying (localized, e.g. "Maximize window") and one for internal use (not localized, e.g. "maximize_window_key"). So to store the shortcuts in xfconf the internal non-localized names are used. The advantage of that is that these settings are locale independent. The downside is that we cannot use them for displaying the window manager action name in the conflict dialog. What we need for this is a way for xfce4-keyboard-settings to query the name from xfwm4. I haven't done this because I think that a D-Bus service for this is a bit of an overkill. I also decided not to display the window manager action names in the conflict dialog of xfwm4-settings for the sake of consistency. > > 2. While you assign a new shortcut to a action you can't use the keyboard in > > any other way. Maybe only grab the keyboard input if the window is selected? > > Not sure that's possible, but... I guess it could work if we react on enter/leave plus focus events from the mouse pointer. I agree the current way is not really ideal and I consider this a bug. > > Would work around the following: > > > > - If the dialog box pops up telling you that the shortcut is already assigned, > > you still have no keyboard control and thus can't use <TAB> or <Enter>. > > That's a separate bug. The dialog should drop its kbd grab in this case, > before displaying the error dialog. Yep. See above. > > 3. You can't scroll in the action list while you are asked for a new shortcut. > > This restricts how to operate the dialog without necessity. For example I > > wanted to find a usable shortcut while the dialog was open but was forced to > > close it because I couldn't scroll. > > There's no way around this. Keyboard grabs are X-server-global; you can't > restrict them to when a specific window has focus (if you could, there'd be > really no point to having them at all in that use case). Again, maybe reacting on certain signals/events might help here. > I suppose it's possible to work on window focus; if you use the mouse to switch > to another window, perhaps we could drop the grab, but then reacquiring the > grab when the shortcut window gets focus again (especially if it gets focus via > one of the WM's keyboard shortcuts) can be unreliable. It sure may be tricky, but I'd like to give it a shot. IMHO it's a bug.
(In reply to comment #5) > > (In reply to comment #0) > > > > > > 1. If you want to assign an already used shortcut to another action it tells > > > you that the shortcut is already assigned but not which one. > > > > Known deficiency. Jannis, I feel like you said there was a technical reason > > for this; even then, we should try to fix this at some point anyway. > > The problem is that the xfwm4 shortcuts have two names: one for displaying > (localized, e.g. "Maximize window") and one for internal use (not localized, > e.g. "maximize_window_key"). [...] > I also decided not to display the window manager > action names in the conflict dialog of xfwm4-settings for the sake of > consistency. Then I disagree with this decision. I'd rather see an untranslated, unfriendly "maximize_window_key" in the dialog until we can come up with a better solution that translates it (I can already think of one such solution that doesn't involve a dbus service: just move all the translated names to libxfce4kbd-private since xfwm4/xfwm4-settings both depend on it) than a semi-useless error message. > > I suppose it's possible to work on window focus; if you use the mouse to switch > > to another window, perhaps we could drop the grab, but then reacquiring the > > grab when the shortcut window gets focus again (especially if it gets focus via > > one of the WM's keyboard shortcuts) can be unreliable. > > It sure may be tricky, but I'd like to give it a shot. IMHO it's a bug. If you're familiar with the xfdesktop menu popup shortcut issue, you'll know we still don't have a solution for this. Even retrying the grab for up to a second after the keybinding is fired doesn't work for some people (but works perfectly for others, like me). It's just highly unreliable and not likely to work everywhere. Although... since I guess the entire point of getting the grab here is... well... getting the grab, it wouldn't hurt to sit there in a loop and keep trying for the grab no matter how long it takes to get it. Of course, if it takes a while, the user will likely have already pressed a shortcut key and be very confused that it hasn't registered. (Of course, the user jumping the gun and pressing more keys will only make it harder for the code to "win" and get a grab.) It's a mess.
(In reply to comment #6) > (In reply to comment #5) > > > (In reply to comment #0) > > > > > > > > 1. If you want to assign an already used shortcut to another action it tells > > > > you that the shortcut is already assigned but not which one. > > > > > > Known deficiency. Jannis, I feel like you said there was a technical reason > > > for this; even then, we should try to fix this at some point anyway. > > > > The problem is that the xfwm4 shortcuts have two names: one for displaying > > (localized, e.g. "Maximize window") and one for internal use (not localized, > > e.g. "maximize_window_key"). > [...] > > I also decided not to display the window manager > > action names in the conflict dialog of xfwm4-settings for the sake of > > consistency. > > Then I disagree with this decision. I'd rather see an untranslated, unfriendly > "maximize_window_key" in the dialog until we can come up with a better solution > that translates it (I can already think of one such solution that doesn't > involve a dbus service: just move all the translated names to > libxfce4kbd-private since xfwm4/xfwm4-settings both depend on it) than a > semi-useless error message. libxfce4kbd-private is a bit of a dirty solution anyway. But you're right, we don't need D-Bus for that. Making "maximize_window_key" appear in the dialog text would break strings. I'm not sure we want to do that again for 4.6. And AFAIR, not all the internal xfwm4 names are as expressive as this one, so I'm not sure exposing external names is a good idea. Better than nothing, maybe ... > > > I suppose it's possible to work on window focus; if you use the mouse to switch > > > to another window, perhaps we could drop the grab, but then reacquiring the > > > grab when the shortcut window gets focus again (especially if it gets focus via > > > one of the WM's keyboard shortcuts) can be unreliable. > > > > It sure may be tricky, but I'd like to give it a shot. IMHO it's a bug. > > If you're familiar with the xfdesktop menu popup shortcut issue, you'll know we > still don't have a solution for this. Even retrying the grab for up to a > second after the keybinding is fired doesn't work for some people (but works > perfectly for others, like me). It's just highly unreliable and not likely to > work everywhere. > > Although... since I guess the entire point of getting the grab here is... > well... getting the grab, it wouldn't hurt to sit there in a loop and keep > trying for the grab no matter how long it takes to get it. Of course, if it > takes a while, the user will likely have already pressed a shortcut key and be > very confused that it hasn't registered. (Of course, the user jumping the gun > and pressing more keys will only make it harder for the code to "win" and get a > grab.) > > It's a mess. Mh, I see. I just took a look at what Terminal does. Apparently it doesn't drop the grab either. I didn't look at the code but it behaves pretty much in the same way. Hm. Maybe there is a way without grabbing? Like listening to keyboard events on the GtkDialog widget or something?
(In reply to comment #7) > Making "maximize_window_key" appear in the dialog text would break strings. I'm > not sure we want to do that again for 4.6. Sure, I'm not suggesting we do. I'm just saying I don't think it was the right way to go. > Mh, I see. I just took a look at what Terminal does. Apparently it doesn't drop > the grab either. I didn't look at the code but it behaves pretty much in the > same way. > > Hm. Maybe there is a way without grabbing? Like listening to keyboard events on > the GtkDialog widget or something? In theory you can use gtk_grab_add() to set one single widget in an application to receive all input events, but I'm not sure how well it works. I'd bet gdk eats some keypresses and modifier state. But if you want to try, go for it. Definitely not for 4.6.0, though. Regardless, that wouldn't fix the issue of being unable to refer to the main shortcuts dialog again and scroll through the list.
(In reply to comment #8) > In theory you can use gtk_grab_add() to set one single widget in an application > to receive all input events Of course, that doesn't really work either, because then other applications can also receive key events if they've grabbed keys. So, for example, if xfwm4 has <Super>w grabbed, and then you use the shortcuts dialog to try to set that to something else, instead of getting the nice conflict dialog, you get xfwm4 performing the action mapped to that key combo. If that action is "close window," you might not be too happy at that point. The only way to do this properly is with a global keyboard grab.
(In reply to comment #4) > Yes, when you write something that amounts to, "I know this is more than one > bug, but I'm too lazy to file more than one," it makes me kinda think, "well > maybe I'm too lazy to help you." Sorry again. It's more of "I don't have enough time to fill a separate bug for everything and if it's related better dump it together instead of filling nothing.". In the first case at least the developer can say no, in the second nobody will ever know. > Anyhow: > > (In reply to comment #0) > > - The window which asks for the new shortcut can be hidden by another window > > and it grabs the input while you are on another workspace without any visual > > notice that it exists. (Makes for some good pranks) > > How would you trigger this? How is it possible to bring up this dialog (which > triggers the grab) while you're on a different workspace? I think you misunderstood what I meant. Think of the following university/school days joke: leave your desktop unattended for half a minute and someone could open the dialog in another workspace, then hide/minimize it using the mouse. For more fun mix with randr which at the moment puts windows really offscreen and thus unreachable for the mouse if you use it in some specific ways. The victim can't both use the keyboard and mouse anymore (except for window minimizing/maximizing/to the front/shade/moving to another workspace with the help of the workspace switcher panel plugin/getting out of X) and is completely fucked. Oh, and if you remove the workspace switcher plugin from the panel he can't even switch anymore... OK it's a highly unlikely scenario, but it shows how bad things can go if the global keyboard grab is activated. > > 3. You can't scroll in the action list while you are asked for a new shortcut. > > This restricts how to operate the dialog without necessity. For example I > > wanted to find a usable shortcut while the dialog was open but was forced to > > close it because I couldn't scroll. > > There's no way around this. Keyboard grabs are X-server-global; you can't > restrict them to when a specific window has focus (if you could, there'd be > really no point to having them at all in that use case). I tried scrolling with the mouse. Are keyboard and mouse handled together?
> Think of the following university/school days joke [...] Yeah, I can't say I'm particularly concerned about this. If someone has physical access to your computer, they can pull any number of pranks. > > > 3. You can't scroll in the action list while you are asked for a new shortcut. > > > This restricts how to operate the dialog without necessity. For example I > > > wanted to find a usable shortcut while the dialog was open but was forced to > > > close it because I couldn't scroll. > > > > There's no way around this. Keyboard grabs are X-server-global; you can't > > restrict them to when a specific window has focus (if you could, there'd be > > really no point to having them at all in that use case). > > I tried scrolling with the mouse. Are keyboard and mouse handled together? Hmm, looking at the code, it looks like we do a keyboard grab, but no mouse grab. I bet the "enter shortcut" dialog is application-modal, though, which would keep any input (mouse or kbd) from getting to the main settings window. Jannis, I guess we could change that, yeah? Keep the little dialog as a transient of the main window, but don't use gtk_dialog_run() and don't make it modal? Does that make sense?
(In reply to comment #11) > > Think of the following university/school days joke > [...] > > Yeah, I can't say I'm particularly concerned about this. If someone has > physical access to your computer, they can pull any number of pranks. Yeah. That's not a particularly useful use case. > > > > 3. You can't scroll in the action list while you are asked for a new shortcut. > > > > This restricts how to operate the dialog without necessity. For example I > > > > wanted to find a usable shortcut while the dialog was open but was forced to > > > > close it because I couldn't scroll. > > > > > > There's no way around this. Keyboard grabs are X-server-global; you can't > > > restrict them to when a specific window has focus (if you could, there'd be > > > really no point to having them at all in that use case). > > > > I tried scrolling with the mouse. Are keyboard and mouse handled together? > > Hmm, looking at the code, it looks like we do a keyboard grab, but no mouse > grab. I bet the "enter shortcut" dialog is application-modal, though, which > would keep any input (mouse or kbd) from getting to the main settings window. > Jannis, I guess we could change that, yeah? Keep the little dialog as a > transient of the main window, but don't use gtk_dialog_run() and don't make it > modal? Does that make sense? That would be fine, I guess.
(In reply to comment #11) > Hmm, looking at the code, it looks like we do a keyboard grab, but no mouse > grab. I bet the "enter shortcut" dialog is application-modal, though, which > would keep any input (mouse or kbd) from getting to the main settings window. > Jannis, I guess we could change that, yeah? Keep the little dialog as a > transient of the main window, but don't use gtk_dialog_run() and don't make it > modal? Does that make sense? If it helps: The mouse "grab" seems global for a lot of gtk2 applications (excluding firefox) not only for the configuration manager. For example I can't open menus in other applications or sometimes scroll but pressing a button or selecting a list element works fine. KDE applications are not affected.
Hello, 1 -> Fixed in git master branch. 2 -> Can't fix due to the limitations explained above. 3 -> Can't fix, the dialogs are modal and should stay so. This is how GTK+ widgets work. Cheers, Jérôme