paperwm / PaperWM

Tiled scrollable window management for Gnome Shell

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Switch windows across monitors and workspaces with the keyboard

ankostis opened this issue · comments

(continuation of #330)

Problem

I'm missing a fast way (single keystroke like Alt+Tab) to cycle between the recently-used windows across all monitors (first) and workspaces (good to have). A case requiring special attention due to its frequent use is to go back quickly (no popup) to the immediately previous window with a singular keystroke.

Note that i'm NOT talking about switching of "Applications", since gnome-shells already offers this operation with a key-binding _"Switch applications" (by default bound to Super+Tab) that selectively includes apps from current/all workspaces or not depending of the "Settings | Multitasking | Include apps from all workspaces/current workspace only". Unfortunately this functionality is particularly cumbersome when switching between windows of the same application (eg. browser), also a very common operation. In that case, many extra cursor keystrokes are needed to select the desired app's window.

Alternatives i've considered

  • PaperWM's "Switch to previously active window/backwards" bindings include windows from current workspace/monitor only.

  • PaperWM's "Switch to the next/previous window" & "Switch to the left/right/... window" bindings include windows from current workspace/monitor only, and that does make sense here. But even if we wanted to retrofit them somehow to include windows from other monitors & workspaces, they would invalidate the recent-activation stack since they activate each window as they traverse them.

  • In vanilla gnome-shell, i switch windows across all monitors simply by using a single workspace on all of them.
    This is impossible with PaperWM which, by design, it uses a different workspace per monitor.

  • When i'm forced to use multiple workspaces, i install extensions like the AATWS.
    Unfortunately all such extensions would fail when switching windows across monitors, I guess, due to the way PaperWM focusing works (it follows the mouse): after selecting the window to switch , eg with Alt+Tab, PaperWM refocuses back to the window in the monitor where the mouse is located (probably not the newly selected monitor).

  • The Switcher extension suffers from the above focusing issue, and requires, best case, +1 keystroke (the final Return to activate the selected window).

  • The only method that i know of to switch to a window on another monitor is first to switch to that monitor (eg. with Super+Shift+Down) and then select the window with any other navigation keystroke.
    Is that correct?

Describe the solution you'd like

I'd envision a new 3-state option controlling what the two PaperWM's key-binding commands "Switch to previously active window/backwards" do:

  • include windows form active workspace only (current monitor, the current behavior)
  • include windows form all monitors (visible workspaces)
  • include windows form all workspaces

Optimally, a configurable delay for skipping the popup would speedup the special "return to previous window" case, like AATWS does it (screenshot from its settings), and in that case, skip the transition animation.
image

Alternatively, teach extensions like AATWS to add an option to move along the mouse pointer, when switching windows :-)

Additional context

  • PaperWM-v71(44.17.0)
  • Gnome Shell-v44
  • Wayland

An alternative implementation i forgot to mention is to simply respect the "Gnome Settings | Multitasking | Include apps from all workspaces/current workspace on" (screenshotted) when switching, and mention in the docs that this generic setting has been given special powers under PaperWM.
image

Hey @ankostis,

For switching to last window used across spaces (workspaces), you can use Gnome's Switch windows directly keybind (default Alt+Escape:

image
image

The above technically works across monitors but I see the issue here re PaperWM's mouse focus in the current monitor will bring focus back to the original monitor. To overcome that - we could warp the mouse pointer on window focus (e.g. to the monitor that has the previously active window).

Note that PaperWM for Gnome 44 isn't being developed further (current support / development is generally targeted at the last 2 Gnome versions, e.g. Gnome 45 & Gnome 46). I can implement the above in the Gnome 45/46, but then it would be up to someone that uses Gnome 44 (and can test in Gnome 44) to backport code changes.

P.S. v44.17.0 is very old now and doesn't have latest fixes/feature etc. Out of interest (feel free not to respond if you don't want to), what's holding you back to moving to Gnome 45/46? Other extensions you use?

P.S.S. I'm a big fan of, and use AATWS. There's an alt+tab clash between PaperWM and AATWS, so a tip here to disable PaperWM's Switch to previously active window... keybinds and use AATWS's instead:

image

(thank you for your prompt response and the time to bake the screenshots)

For switching to last window used across spaces (workspaces), you can use Gnome's Switch windows directly keybind (default Alt+Escape:

Nope :-(
To me, it switches to the previous window in the current workspace, as all other key-bindings.
So if it technically only works, but not actually, then maybe the other bindings fall in this category, broken by focus.

Anyhow, even if it worked, i consider this gnome binding a waste, needing to train fingers for one shortcut when switching 1 window back, and another for 2, 3, ... better to render the single case fast with a time-delay, as AATWS's extension has done, and preserve some mental workload for the user.

There's an alt+tab clash between PaperWM and AATWS, so a tip here to disable PaperWM's Switch to previously active window... keybinds and use AATWS's instead:

Thank you for the tip, that had missed me.
In any case, i'm always using the Alt+Tab keystroke in my experiments, so i was not affected - actually i've never used Super+Tab in AATWS before.

Out of interest (feel free not to respond if you don't want to), what's holding you back to moving to Gnome 45/46? Other extensions you use?

I'm on debian unstable("sid"), and that is what it installs for me. I'm also surprised annoyed it does not bring me the very latest.

v44.17.0 is very old now and doesn't have latest fixes/feature etc.

According to the reddit above, both 45 & 46 are still considered unstable [by debian devs], mostly due to switching
to magpie, a fork of mutter
, and debian only includes those versions in "experimental"; a leap of faith too big even for me :-)

So although PaperWM v44 had grown old, gnome-shell v44 is still alive and kicking.
Maybe it's worth the effort for a PR.

Would it be hard to retrofit the window-collection code to respect gnome's option?


TL;DR, do you imply that my woes would go away when Debian switches to more recent gnome-shell versions?

Nope :-(
To me, it switches to the previous window in the current workspace, as all other key-bindings.

Ah, yes, you're right. Disabling PaperWM this is the case as well (gnome behaviour for switch directly keybind).

Unfortunately Gnome 44 is no longer supported by Gnome (EOL) as of March 16th: https://release.gnome.org/calendar/
In any case, we could add keybinds to collect windows across all spaces. Will look at this at some point.

Maybe it's worth the effort for a PR.

Always happy to accept a PR!

Don't forget the would-accept-PR label, maybe someone with a more credible experience in javascript [than me] can scratch this itch :-)

So, I can confirm that on Gnome 45/46, and the latest PaperWM (version 46.6.4), default PaperWM alt+tab does move through all windows across spaces and monitors.

i.e. Switch to previously active window will iterate through all windows across space and monitors (not just those on the current space).

I've implemented warping to the mouse pointer to the correct monitor (if alt+tabbing selects a window on another monitor), and will do some more tests before looking at merging this change into latest develop branch.

As far as I can remember, this has always been the behaviour (alt+tab moves through all windows across spaces/monitors). @Lythenas - are you seeing the behaviour mentioned by @ankostis (e.g. alt+tab only iterating through windows on a space?).

I might install a clean/fresh Gnome 44 vm and see if I can reproduce what @ankostis is seeing.

@ankostis - are you running any other extensions that might impact alt+tab? For a test, can you disable all other extensions (except PaperWM), log-out, log-in and see if you're still seeing this?

Also, I just noticed this (mainly because I usually don't use multiple monitors) but it seems somewhat annoying that PaperWM alt+tab only show on primary monitor (instead of the current monitor). I might look at changing that too while we're looking at this.

@ankostis, so - yes, there is a difference in behaviour here between behaviours in Gnome 44 and Gnome 45/46. I can't remember if we changed this behaviour or it was something that changed in Gnome 45+.

In PaperWM 45.7.0 we added alt+tab as a default keybind (see #737). It could have been in #789 where I changed to this behaviour.

TL;DR, do you imply that my woes would go away when Debian switches to more recent gnome-shell versions?

I believe so (update to at least Gnome shell 45 and the latest PaperWM version).

An alternative implementation i forgot to mention is to simply respect the "Gnome Settings | Multitasking | Include apps from all workspaces/current workspace on" (screenshotted) when switching, and mention in the docs that this generic setting has been given special powers under PaperWM. image

Thanks @ankostis - see PR #839. I've now implemented the respecting of this in PaperWM alt+tab switching. The changes in this PR should fix the main issues mentioned here.

Recommend you update to Gnome 45/46 once #839 is merged and released.

,Oh, i crave for a backport of this into v44, can't really update gnome-shell on Debian without breaking the universe.
I will try to merge it my self and test my gnome-shell with local installation of the extension.
Do you think this would work?

[and a big thank you]

Alternatively, you can run:

dconf write /org/gnome/shell/window-switcher/current-workspace-only false

to show all windows from all workspaces in Gnome 44 PaperWM. But note that you'll still have the window-on-another-monitor focusing issue (which you'll need #839 to fix).

without breaking the universe

Well, given I live in this universe as well.. I definitely don't want you breaking it.

I'll see if I can backport the main parts of it.

Do you think this would work?

Probably not, I did some linting and cleanup while I was there as well. But the relevant parts you'd need aren't that large.

Dang it - as I feared. Unfortunately, the porting won't work on Gnome 42-44. Those older version for PaperWM (for older Gnome versions) used a very old (and error-prone) implementation to isolate workspaces to monitors (e.g. per monitor workspaces).

Gnome 45 was in many ways a fairly large refactor/rewrite of many areas of PaperWM (largely by necessity as Gnome 45+ moved to standard js ESM (modules) for all extensions). On a sidenote, it was about 11,000 line changes to PaperWM moving from Gnome 44 to 45+ (which included a lot of fixes and other improvements).

Hence, it's not feasible for me to keep working on Gnome 44, especially since it's EOL.

Hopefully Debian unstable will allow using later/current versions of Gnome a bit easier soon.

At least with that dconf setting above you'll be able to switch between windows of other workspaces a bit easier.

Closing as fixed by #839.