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

Clarify the constraints around not following windows to spaces #1713

Open
maciejtulaza opened this issue Jan 3, 2025 · 2 comments
Open

Clarify the constraints around not following windows to spaces #1713

maciejtulaza opened this issue Jan 3, 2025 · 2 comments
Labels

Comments

@maciejtulaza
Copy link

Describe the bug
When I am trying to throw a focused window to a different space with shortcut ctrl+option+shift+1/2/3/etc. the window gets moved but I am also switched to that space together with the window. That was not the behaviour in previous versions. Before I raised a bug that in a 0.21.x versions this feature did not work at all on MacOS Sequoia 15.1.1 (24B91). After 0.22.0 update it works but behaves as I describe. It was much more useful when I could throw the windows around and stay where I am. If "this is a feature not a bug" then I'd definitely like to see this being an option in settings.

Applications:
Any app managed by Amethyst

To Reproduce
Install 0.22.0 Amethyst, in my case MacOS Sequoia 15.1.1 (24B91) but probably same for other builds of sequoia.

Expected behavior
When pressing the shortcut ctrl+opt+shift+1/2/3/etc the focused window gets moved to chosen space but I stay on the space I currently am - space is NOT switched.

Screenshots
I hope descriptions are clear enough.

Versions:

  • macOS: MacOS Sequoia 15.1.1 (24B91)
  • Amethyst: 0.22.0 updated from 0.21.x version

Debug Info

$ /Applications/Amethyst.app/Contents/MacOS/Amethyst --debug-info [--include-apps]
Version: 0.22.0 (119)

OS version: Version 15.1.1 (Build 24B91)

Screens:
	(0.0, 0.0, 5120.0, 1440.0) [(0.0, 0.0, 5120.0, 1440.0)]

Configuration:
floating-is-blacklist: 1
float-small-windows: 1
mouse-follows-focus: 0
window-margin-size: 2
window-minimum-width: 0
floating: (
        {
        id = "com.apple.systempreferences";
        "window-titles" =         (
        );
    },
        {
        id = "jp.plentycom.app.SteerMouse";
        "window-titles" =         (
        );
    },
        {
        id = "com.apple.finder";
        "window-titles" =         (
        );
    }
)
mod1: (
    option,
    shift
)
screen-padding-left: 0
window-minimum-height: 0
focus-follows-mouse: 0
window-margins: 1
mod2: (
    option,
    shift,
    control
)
use-canary-build: 0
screen-padding-top: 0
smart-window-margins: 0
window-max-count: 0
window-resize-step: 5
enables-layout-hud-on-space-change: 1
new-windows-to-main: 0
debug-layout-info: 0
restore-layouts-on-launch: 1
layouts: (
    "middle-wide",
    "two-pane",
    fullscreen
)
screen-padding-right: 0
follow-space-thrown-windows: 1
screen-padding-bottom: 0
enables-layout-hud: 1
ignore-menu-bar: 0

Additional context
Nothing really

@maciejtulaza
Copy link
Author

I can update that it works exactly the same for MacOS M3 Pro Sonoma 14.6 where I have just installed it

Any plans to work on this?

@ianyh
Copy link
Owner

ianyh commented Jan 25, 2025

Unfortunately, with the new constraints on how moving between spaces works, there is no way to not follow the window. The best that can be done is to move back to the previous space afterwards, but the animations make that awkward.

@ianyh ianyh changed the title Throw focused window to another space also switches to that space Clarify the constraints around not following windows to spaces Jan 25, 2025
@ianyh ianyh added the bug label Jan 25, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants