GNOME Bugzilla – Bug 155216
alt-button in alt-tab window
Last modified: 2020-11-07 12:36:41 UTC
It would be a good enhancement to be able to push alt-tab, and then push Q while holding alt to close the program that's selected. This is a Mac OSX thing, and I like it. It might be useful to have other key bindings too, maybe f4 while holding alt do the same thing. You could push spacebar (while holding alt) to bring the window to the front. Maybe alt-ctrl-z to bring up the force quit dialog (the one saying "are you sure," not the one saying click an application to quit).
Note that it's not necessarily Alt-Tab. E.g., I use Super (aka Windows aka Mod4) key for all operations on windows, including Super-Tab to switch between them and Super-X to close it. It's a question of keybindings, and by the way, one may have something else bound to (in your case) Alt-Q. Anyway, I'd be glad to see doing things on windows without releasing the modifier. Currently, if I started switching windows, I must release the modifier to actually choose the window, and only after that I have an opportunity to move it (by means of modifier+mouse or modifier+key), or resize, or close, by a separate key combination.
The must-release-the-modifier problem is already filed as bug 112560...
Elijah: Thank you for a pointer. Seems like this bug is a dup then?
Some of it is, but it also contains extra suggestions about enabling more keys, the main one being <modifier>-Q; and I'm think of this bug as being totally about that half. Since it's marked as an enhancement instead of as a real bug, I think that makes sense.
Created attachment 59622 [details] [review] Honour the window bindings if used to end cycling There are really three ways we can do this: A) Make up a whole new set of bindings specially for window management during cycling (e.g. Q for close window). This is how the Mac does it. B) Use the existing window bindings. C) Both. This patch goes with option A. This means that 1) We have to end cycling when you press a window management key. This is because some of the operations involve starting a new grab. This wouldn't be a problem with option B. 2) It's not possible with some sets of keys. E.g. if your cycling key is alt-Tab and your window close key is super-F10, you can't press window close without letting go of Alt and ending cycling. I'd be interested to hear what you think.
Er. I got A and B backwards. Serves me right for writing the comment in a hurry. Let's try again. There are really three ways we can do this: A) Make up a whole new set of bindings specially for window management during cycling (e.g. Q for close window). This is how the Mac does it. B) Use the existing window bindings. C) Both. This patch goes with option B. This means that 1) We have to end cycling when you press a window management key. This is because some of the operations involve starting a new grab. This wouldn't be a problem with option A. 2) It's not possible with some sets of keys. E.g. if your cycling key is alt-Tab and your window close key is super-F10, you can't press window close without letting go of Alt and ending cycling. Again, this wouldn't be a problem with option A, assuming we didn't let them specify modifiers. Doing option A would be broadly similar to this patch, but would also need two more changes: i) another set of gconf prefs to specify what the new bindings were ii) redisplaying the tab popup after processing the new keystroke, since one of the windows may have disappeared.
Cool, it looks like you have a partial fix for bug 112560. I think we need to fix that more general bug, though, instead of just getting specific cases (e.g. Ctrl-Alt-right to switch workspaces, release ctrl, press tab to switch windows and notice that it merely ends the workspace switch op instead of also starting a window switch op). So we should probably have the more general patches attached to that bug too. One note on the patch -- isn't it possible to just switch the grab type instead of ending the grab op and starting a new one (kind of like Ray did with process_keyboard_resize_grab_op_change())? That would seem cleaner. Anyway, this is really cool that you're working on this.
I believe the patch in bug 112560 solves the same problem more elegantly.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old feature requests in Bugzilla which have not seen updates for many years. If you still use metacity and if you are still requesting this feature in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/ Thank you for reporting this issue and we are sorry it could not be implemented.