GNOME Bugzilla – Bug 705434
Add "Switch to next window" method
Last modified: 2021-07-05 14:37:27 UTC
The Chromebook pixel has a "switch to next window" button that should be mapped to this function by default. This involves udev keymap changes, as well as gnome-settings-daemon changes. To minimise the changes to the shell, we should just expose a new D-Bus method for g-s-d to use. The behaviour is slightly different from the Alt+Tab model where you have a modifier that you can keep pressed to cycle through the list (and show an MRU list of windows/apps). https://support.google.com/chromeos/answer/1047364?hl=en
We already have a keybinding for "switch to next window immediately" (alt-escape), we should not ping pong between gnome-shell and gnome-settings-daemon, especially if this button is going to be used often (which seems to be the case). Just add the new keysym as a default secondary binding.
We can't... Aug 05 10:10:59 sirocco.hadess.net /etc/gdm/Xsession[480]: Aviso do gerenciador de janelas: Cannot bind "cycle-windows" to F8: it needs a modifier such as Ctrl or Alt.
(In reply to comment #2) > We can't... > > Aug 05 10:10:59 sirocco.hadess.net /etc/gdm/Xsession[480]: Aviso do gerenciador > de janelas: Cannot bind "cycle-windows" to F8: it needs a modifier such as Ctrl > or Alt. Oh! The reason that check was added is bug 329676: pressing the combination twice would go back and forth between two windows, rather than following the list, because there is no Alt modifier to keep the switch "alive". I don't know if that would be a problem for the physical key too.
So we need a new binding :)
(In reply to comment #4) > So we need a new binding :) Not really: doing anything else than following the MRU list is wrong, and you need to keep that updated for the other bindings and window switchers. So you would always have that problem.
Then we either need not to update the MRU when using this binding, so it doesn't just toggle between 2 apps, or we need a better way to determine when to update the MRU (for example, when interacting with the window with the keyboard or pointing devices, not when focusing it). We need to make this key work...
(In reply to comment #6) > Then we either need not to update the MRU when using this binding, so it > doesn't just toggle between 2 apps Maybe a small timeout would be the least surprising thing to do? Not updating the MRU at all would not only break other bindings, it would also be confusing when not getting back to the original window after spending 5 minutes or so reading something in the browser window. > or we need a better way to determine when > to update the MRU (for example, when interacting with the window with the > keyboard or pointing devices, not when focusing it). I think there are valid cases for spending time in a window without interaction (see above) ...
A timeout when using an unmodified key seems like a good solution to the problem.
*** Bug 709327 has been marked as a duplicate of this bug. ***
The T440s seems to have a similar key (Fn+F11). It's documented (http://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles_pdf/t440s_ug_en.pdf page 26 or http://www.thinkwiki.org/wiki/Default_meanings_of_special_keys ) as showing all the programs which are opened, but forum posts ( http://forum.notebookreview.com/lenovo/732797-thinkpad-t440s-review-32-print.html ) say that Windows handles it as alt-tab: "the F11 function seems to just replicate Alt+Tab"
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.