Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch windows across monitors and workspaces with the keyboard #837

Closed
ankostis opened this issue Apr 24, 2024 · 15 comments
Closed

Switch windows across monitors and workspaces with the keyboard #837

ankostis opened this issue Apr 24, 2024 · 15 comments
Labels
enhancement Adds a new feature or extends scope fixed-in-more-recent-version Issue described has been fixed in a more recent version of PaperWM gnome-44 Specific to GNOME Shell 44

Comments

@ankostis
Copy link

ankostis commented Apr 24, 2024

(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
@ankostis ankostis added the enhancement Adds a new feature or extends scope label Apr 24, 2024
@ankostis
Copy link
Author

ankostis commented Apr 24, 2024

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

@jtaala
Copy link
Collaborator

jtaala commented Apr 24, 2024

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

@ankostis
Copy link
Author

ankostis commented Apr 24, 2024

(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?

@jtaala
Copy link
Collaborator

jtaala commented Apr 24, 2024

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!

@ankostis
Copy link
Author

ankostis commented Apr 24, 2024

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

@jtaala jtaala added the would-accept-PR Would accept PR if someone is interested in working on this label Apr 25, 2024
@jtaala
Copy link
Collaborator

jtaala commented Apr 25, 2024

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.

@jtaala
Copy link
Collaborator

jtaala commented Apr 25, 2024

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?

@jtaala jtaala added can't reproduce Issue doesn't happen on our end and removed would-accept-PR Would accept PR if someone is interested in working on this labels Apr 25, 2024
@jtaala
Copy link
Collaborator

jtaala commented Apr 25, 2024

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.

@jtaala
Copy link
Collaborator

jtaala commented Apr 25, 2024

@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).

@jtaala jtaala added gnome-44 Specific to GNOME Shell 44 and removed can't reproduce Issue doesn't happen on our end labels Apr 25, 2024
@jtaala jtaala added the fixed-in-more-recent-version Issue described has been fixed in a more recent version of PaperWM label Apr 25, 2024
@jtaala
Copy link
Collaborator

jtaala commented Apr 25, 2024

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.

@ankostis
Copy link
Author

ankostis commented Apr 25, 2024

,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]

@jtaala
Copy link
Collaborator

jtaala commented Apr 25, 2024

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).

@jtaala
Copy link
Collaborator

jtaala commented Apr 25, 2024

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.

@jtaala
Copy link
Collaborator

jtaala commented Apr 25, 2024

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.

jtaala added a commit that referenced this issue Apr 26, 2024
Fixes a related issue partly described in #837.

Note that in Gnome 45+, PaperWM `alt`+`tab` does indeed switch through
all windows across spaces and monitors (by default). However, an issue
does occur that if we switch to (and focus) a window on another monitor
via `alt`+`tab` etc., when we move the mouse focus will be pulled to the
monitor that the mouse is on.

This PR fixes this by warping the mouse pointer to the new monitor if
needed (along with a mouse pointer ripple effect).

This PR also now links the behaviour for showing `all` windows or `only
windows from current space` in PaperWM to the Gnome Multitasking
setting:


![image](https://github.com/paperwm/PaperWM/assets/30424662/b49736a5-a105-4534-a98b-2300f5a399e0)
@jtaala
Copy link
Collaborator

jtaala commented Apr 26, 2024

Closing as fixed by #839.

@jtaala jtaala closed this as completed Apr 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Adds a new feature or extends scope fixed-in-more-recent-version Issue described has been fixed in a more recent version of PaperWM gnome-44 Specific to GNOME Shell 44
Projects
None yet
Development

No branches or pull requests

2 participants