MACROS: Desktop Spaces • Macros to Improve Navigation and Window Management, v2.0

No problem; I enjoy helping others with challenges like this.

Only because you said that the AppleScript seemed to work better from the Script Editor, I think it might be worth testing this slightly revised approach:

DOWNLOAD Macro File:
zGetDesktopNo Test v2.kmmacros (13 KB)
Note: This macro was uploaded in a DISABLED state. It must be ENABLED before it can be run. If it does not trigger, the macro group might also need to be ENABLED.

Macro-image


Also, even if this doesn't work, I think this would be worth revisiting once Monterey is revised beyond v12.3.

Curiouser and curiouser...

Run #1 had me excited:
local_DesktopNo [3]

START Time: 70592.852918
END Time: 70593.10928
DURATION: 0.256362 sec

But then:
local_DesktopNo [2]

START Time: 70617.105974
END Time: 70619.966049
DURATION: 2.860075 sec

And then back to Desktop 3 to see if there was something special about that, but no:

local_DesktopNo [3]

START Time: 70722.791659
END Time: 70731.557042
DURATION: 8.765383 sec

I sure wish I had an Apple Silicon machine so I could do more testing, but short of that, here's another revision to try. It's a bit slower on my Intel Mac, but hoping it might yield more consistent results on your Studio.

DOWNLOAD Macro File:
zGetDesktopNo Test v3.kmmacros (13 KB)
Note: This macro was uploaded in a DISABLED state. It must be ENABLED before it can be run. If it does not trigger, the macro group might also need to be ENABLED.

Macro-image

Pretty much the same pattern. Good result on Desktop 3 first time around, but not the second time, so seemingly not desktop-specific. In the order I ran them:

local_DesktopNo [2]

START Time: 82849.869349
END Time: 82865.350882
DURATION: 15.481533 sec


local_DesktopNo [3]

START Time: 82884.58118
END Time: 82885.333274
DURATION: 0.752094 sec


local_DesktopNo [1]

START Time: 82901.161815
END Time: 82905.271383
DURATION: 4.109568 sec


local_DesktopNo [3]

START Time: 82919.705455
END Time: 82925.204339
DURATION: 5.498884 sec

Sorry to hear that. Let's revisit this post Monterey v12.3.

Hi @rolian,

Looks like at least one other AppleScript issue has been addressed with macOS12.3.1. If you’ve updated, it might be worth checking the behavior of the WhichSpace AppleScript.

Hi @_jims,

I updated to 12.3.1 but don't see any real difference. The macro group still doesn't work for me, and the three test macros you'd sent still yield times in the 4 to 10 second range. I have an idea though - I'm going to see if I can carve off just the part of your macro that puts and holds the cursor by the "stoplights" and then use that as the first action in a StreamDeck multi-action. The second action will be to use the system hot-key for switching to a desktop (e.g. ctr-opt-comd-{# of desktop}. May not get to try this until tomorrow, but will certainly keep you posted.

Thanks for reporting back. Maybe it’s related the Apple Silicon processor, however, it seems odd because the AppleScript is very simple.

I’m curious, when you switch spaces, does the WhichSpace menubar number immediately indicate the proper Desktop Space number (i.e., 1, 2, 3, …) or is there a delay in the proper indication?

Well, I've been dumb not to try what I've now tried - I modified your macro as follows - I took out the subroutine altogether and hardcoded the desktop switch. What is bizarre to me now is that this doesn't work either - I get a little "bloop" sound at the point where the "Type the Keystroke" action is. BUT, if I disable the "type the keystroke action" and manually type the keystroke during the interval when the macro is paused, everything is hunky-dory. I've checked and there are no KB conflicting hot-keys, and I don't think there are conflicts anywhere else or I wouldn't expect the manual entry of the key combo to work.
In short, I don't think the problem is Apple Silicon, I don't think the problem is WhichSpace, I know the problem is not your macro, and I am clueless as to what the problem might be. The "Type a Keystroke" action works just fine for me in zillions of other KB macros.

And to answer the question you asked, when I switch desktops either by ctrl-arrow or the #-specific combo, WhichSpace indicates the proper # right away.

I have dinner guests showing up in 10 minutes, so I won't be able to pursue this further tonight, but will take a look at it with fresh eyes in the morning.

EDIT: In case it isn't clear, ctr-opt-cmd-keypad2 is my shortcut set in sysprefs to move to Desktop 2; The other desktop switch shortcuts are the same, other than the number obviously .
sub—Move Window to Desktop N copy Macro (v10.0.2)

sub—Move Window to Desktop N copy.kmmacros (11 KB)

1 Like

Hi @rolian. As I'm sure you know, you are not using the Mission Control Keyboard Shortcuts that I use and are defined in the downloaded version of sub—Type Keystroke for Switch to Desktop N. Instead it seems you are using keypad numbers. That's very interesting; on my Mac I'm not able to differentiate the 1's. Hopefully, this annotated screenshot will clarify that point.

Mission Control Keyboard Shortcuts

If you are able to differentiate the 1's on your Mac when setting macOS Keyboard Shortcuts*, then there must be some difference with our macOS preferences.

Secondly, due to the issues mentioned in Simulate Keystroke Not Working in Mojave I suspect that Keyboard Maestro would not be able simulate these keys with the Type a Keystroke action.


*On my Mac, unlike with macOS Keyboard Shortcuts, the 1's are differentiated when I set KM hot keys.

You, sir, are a genius!!

  1. Your footnote about the differentiation between macOS Keyboard Shortcuts and KB hotkeys set me on the right path, though I am not sure the footnote is exactly right - more on that below.

  2. You are correct that a 4 and a keypad-4 are different, and I had made the appropriate changes in your macro per the instructions and had put keypad-#s in all the appropriate spots. And you are also correct that changing the settings in SysPrefs doesn't SHOW a difference between a # and its keypad-# equivalent. BUT it does differentiate between them. So when I used Keypad-#s in the system shortcuts, it LOOKED JUST LIKE using regular numbers, but when keystroking it, it worked correctly using the keypad-# but not the regular #. I would call that a bug in the user interface, but the ultimate behavior is exactly what is expected, so no biggie. So I do think the numbers ARE differentiated with macOS Keyboard Shortcuts - it is just that there is no visible evidence of it in the settings. As an aside, I was using the keypad-# scheme instead of the one you defined in the macro because some of the "regular" number shortcuts were already taken in my system for conflict palettes and I didn't want to have to change a couple of dozen KM hotkeys. Using the keypad-# scheme let me have consistency without any such conflicts. Unfortunately, the consistent thing was that it didn't work and I came to the forum to figure out why.

  3. I had carefully read the messages in Simulate Keystroke Not Working in Mojave as you had suggested earlier, but was misled by the line in one of Peter's posts about simulated keystrokes only working with letters - I figured "that obviously isn't the case anymore because Jim's macro simulated keystrokes with numbers" and I was not trying to use the special characters that were the focus of that thread. But after reading your footnote I decided to test the Simulate Keystroke action and, lo and behold, it DOES NOT WORK with the numeric keypad, even though it works with "regular" numbers. In short, you nailed it much earlier in this thread, but I was lost in the weeds and didn't appreciate your perspicacity.

  4. In looking at this from scratch this morning with the benefit of the additional clarity I gleaned from your footnote, I said to myself "just for kicks, let's set a Mission Control desktop shortcut to a letter and see what happens".

Being the smart guy you are, you can guess the ending. YOUR MACRO WORKED!!

I am happy that it now works and happier that you taught me something about the keypad that I wouldn't have figured out in a million years - I use the numeric keypad in lots of KM hotkey triggers, and the seemingly subtle difference (albeit with enormous practical consequences) between hotkey triggers and simulated keystrokes would never have occurred to me. My wife is happy because the difference between being able to use your macro and make efficient use of Desktops or not might have been the need to go out and blow $1600 on a second Studio Display. Hopefully with the facile use of Desktops now, I can avoid that.

So, thank you again for sticking with me through what is now post #24 in this thread. I am a big puzzle fan and hate it when they are unsolvable - glad that this one ultimately had a solution.

1 Like

The problem turns out to be the Stream Deck Zoom plugin - it causes major issues with scripts that "Tell System Events.." Deleting the plug-in solved the issue.

2 Likes

Good catch!

1 Like

Three macros in this group, .sys Desktop Spaces, have been revised to v1.1:

  1. macro: Go to Previous Desktop

    Bug fix: local_dnPreviouslySaved was improperly determined.

  2. macro: Move Window to Previous Desktop

    Removed an extraneous local_dnTarget Set Variable to Text action. No change to macro functionality.

  3. macro: sub—Activate an App and Wait Until It Is Ready

    Added provision for applications that have a null %FrontWindowName%.


Installing the Revised Macros.

If you have NOT installed the macros in this thread, refer to the first post in this thread and follow to the Installation section. The zip file has been updated with the three revised macros.

If you previously installed the macros in this thread:

  1. In group .sys Desktop Spaces, delete the three macros that have been revised.

  2. Click to download the following:

    3 Desktop Spaces Macros-v1.1.kmmacros (72.2 KB)

  3. Double-click the downloaded file to install the revised versions of the three macros.

Is there an easy way to change the ⌃D shortcut for multiple entries at a time? I already use that in multiple applications (terminal sessions, for one, where it's used to send an EOF) and changing it in 43 macro entries is not looking like it's going to be fun…

I'm guessing I could write a macro to edit the macros :grin:

Or try these…

Thanks — that took a bit of tweaking, but I've got there. All I have to do now is remember what I set it to the next time I go to use it!

1 Like

Great macro @_jims and although it makes my life a little easier it doesn't solve my main flaw with spaces - that of names for each space.

I am using a clunky floating sticky with the name of the space in each space and a KM macro to switch to that named sticky from the dock.

Are there any plans to tie a name to each space?

Thanks

Hi, @nickwild; glad you find the macro set useful.

No, but you might want to see how I use the Desktop Spaces subroutines to create simple macros that are both application and task related:

Workspaces in Mission Control Desktop Spaces - Questions & Suggestions - Keyboard Maestro Discourse

@_jims After deleting the prior version of the macros and installing the version from this thread I'm still having difficulties :frowning_face:

I'm running 12.4 on an M1 Mini. I've set the desktop shortcuts as requested and they work. I have Whichspace running.

  • Using Cntl Arrows to move between spaces works!
  • Using Cntl-Cmd Arrow to move an app right or left a desktop results in the cursor moving to the upper left corner, then moving back to it's prior position.
  • Cntl-Cmd 2 also moves the cursor in the same way.

I downloaded your test script zGetDesktopNo Test.kmmacros and my results look like yours.

Thanks for any help you can give.