Note: Before bug reporting, please make sure you have tried the latest (alpha) version of BetterTouchTool and that you have already tried to restart your system :-). If you encounter a crash, please attach a crash log from the macOS Console.app from the "User Diagnostic Reports" section.
Describe the bug
I think there could be a bug causing this in BetterTouchTool. It's been occurring somewhere in the realm of a month or two. I am running an external display that hosts spaces 1-10 and the MacBook display beneath it hosts spaces 11 & 12
My hotkeys for space management are
Shift+Ctrl+1 => "Move to Desktop 1"
Shift+Ctrl+2 => "Move to Desktop 2"
...
Shift+Ctrl+9 => "Move to Desktop 9"
Shift+Ctrl+0 => "Move to Desktop 10"
For some reason Shift+Ctrl+9 sends it to Desktop 10 instead of to Desktop 9! All the others function as expected. I've tried deleting and recreating the rule. I've tried rebooting. I've tried deleting and recreating the spaces.
Mind taking a look if it could be a bug?
Affected input device (e.g. MacBook Trackpad, Magic Mouse/Trackpad, Touch Bar, etc.):
N/A
Screenshots
If applicable, add screenshots to help explain your problem. (You can just paste or drag them here)
Device information:
- Type of Mac: 16inch M1 MacBook Pro
- macOS version: Ventura 13.1
- BetterTouchTool version: 4.062 (but I have experienced the issue for some time now)
**Additional information (e.g. StackTraces, related issues, screenshots, workarounds, etc.)
Thanks for taking a look! I love this software. Huge fan.
@Andreas_Hegenberg Hi Andreas, I was wondering if you would be willing to spare a moment soon to peek at this issue. It is still plaguing me and I haven't been able to find a workaround of any kind.
I have more clues for you.
As mentioned, I use Spaces 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
And I have 10 hotkeys
My hotkeys for space management are
Shift+Ctrl+1 => "Move to Desktop 1"
Shift+Ctrl+2 => "Move to Desktop 2"
...
Shift+Ctrl+9 => "Move to Desktop 9"
Shift+Ctrl+0 => "Move to Desktop 10"
I press Shift+Ctrl+9 and I verify that hotkey was invoked, because I see the correct HUD overlay text.
If I have only spaces 1 thru 9, then it lands on Desktop 9 indeed!
But as soon as I have 10 or more spaces, the window incorrectly lands in Desktop 10.
It seems to make no difference whether or not I have a single display or mutliple displays active. The issue will always happen when I have 10 or more spaces, then "Move to Desktop 9" lands on Desktop 10 instead.
I've tested the usual suspects, such as deleting and recreating rules, uninstalling and reinstalling, etc. But the issue persists.
I've experienced this issue since 4.062 and perhaps earlier. It persisted continually. I am now on macOS 13.6.6 and BTT 4.389
Thank you so much! I love this software.
Does it work with the default shortcuts in System Settings => Keyboard => Keyboard Shortcuts => Mission Control? BTT basically just uses these.
@Andreas_Hegenberg I wonder if we're not on the same page. I feel like you're what you're pointing to in Mission Control is "Switch to Desktop N". Whereas the source of my issue is actually the "Move Window to Desktop 9" directive that only seems to exist in BTT from what I can tell. Is that making sense? Or am I still missing something here? Thanks.
that’s essentially the same. If you drag a window while executing the “switch to desktop” actions, it will move the window. (that’s what btt does to move a window to a different desktop)
@Andreas_Hegenberg Gotcha. In short, the answer is yes, it does work natively with the shortcuts defined inside System Settings => Keyboard => Keyboard Shortcuts => Mission Control.
I did some further testing & here are my observations.
NOTE: My definitions for "Switch to Desktop N" are defined in the native MacOS settings inside System Settings => Keyboard => Keyboard Shortcuts => Mission Control. The shortcut is always "Ctrl+N" and they are defined for desktops 1 through 10 only.
TEST A: (the original failure mode) I invoke BTT "Move [Window] to Desktop 9" using Shift+Ctrl+9.
OUTCOME: Fail. Does not match expectation. It seems that if there are 10 or more Desktops, the window is moved to Desktop 10. It does not matter which Desktop the window started in. Weirdly, "Move to Desktop N" behaves correctly for other values of N and only N=9 exhibits these flaws.
TEST B: (using MacOS shortcuts only) I manually "drag" my window by clicking and holding mouse on the top bar and invoking the native definition of "Switch to Desktop 9" by pressing Ctrl+9.
OUTCOME: Success. Matches expectation. Window is moved to Desktop 9
TEST C: I change my BTT shortcut for invoking "Move [Window] to Desktop 9" to "Shift+Ctrl+Cmd+L". (something obscure that hopefully no other application on my system is using). Then I invoke BTT-defined "Move [Window] to Desktop 9".
OUTCOME: Fail. Behavior matches original failure mode as described in "a)"
TEST D: Disable the native MacOS shortcut for "Switch to Desktop 9" (unchecking the box). Then invoke BTT "Move [Window] to Desktop 9" with the BTT-defined shortcut.
OUTCOME: Fail. Behavior matches original failure mode as describe in "a)"
TEST E: Re-enable & change the native MacOS shortcut for "Switch to Desktop 9" to "Shift+Ctrl+Alt+Cmd+9" (something obscure that hopefully no other application on my system is using). Then I invoke BTT-defined "Move [Window] to Desktop 9" using "Shift+Ctrl+9".
OUTCOME: Fail. Behavior matches original failure mode as describe in "a)"
TEST F: Try checking "Prevent Recursive Triggers" in the BTT-definition that maps "Shift+Ctrl+9" to "Move [Window] to Desktop 9". Then I invoke BTT-defined "Move [Window] to Desktop 9" using "Shift+Ctrl+9".
OUTCOME: Fail. Behavior matches original failure mode as describe in "a)"
TEST G: Disable all native MacOS mission control shortcuts. Redefine them in BTT. Then I invoke BTT-defined "Move [Window] to Desktop 9" using "Shift+Ctrl+9".
OUTCOME: Fail. Behavior matches original failure mode as describe in "a)"