Waiting on the Spinning Wheel of Death?

Does anybody know a way to pause a macro until a non responsive app wakes up? In other words, pause until the spinning wheel of death disappears?

I'm wondering if a query to System Events might fail to complete until the process reestablishes communications with the windowing system. Perhaps waiting on something like the following:

tell application "System Events"
	tell process "<processname>"
		set w to window 1
	end tell
end tell

This is a complete stab in the dark, and since the problem is intermittent it's difficult to test. Thoughts?

Hey Jeff,

Try using a Pause Until action with a text condition.



Make sure you give the action a timeout (available from the gear menu or contextual menu).

If that doesn't work then you might want to run the command line utility top in logging mode and look for your non-responsive app.


I found a temporary fix. Just keep trying to click on the thing that I'm trying to click on until it finally goes away. :wink: But I will definitely try your ideas! This is not the first time I've bumped into the problem. (It would be nice if there were a "Wait until application is responsive" option in KM.) Thanks!

That might be more difficult to do than you think, and there's a way to manage it for most apps already:

Note -- these are actions and will install in the macro currently being edited.

Keyboard Maestro Actions.kmactions (1.8 KB)

Keyboard Maestro Export

You would want to have a reasonable time-out period. (See the gear menu or contextual menu of the pause-until action.)

Whups... This might not work, because you can't make it app-specific...

It could probably be done with AppleScript UI-Scripting though.

If I was dealing with a specific known application I might do something like this:

Keyboard Maestro Actions.kmactions (2.6 KB)
Keyboard Maestro Export

You aren't saying that there are limits to Peter's ability to do magic, are you???? :wink:

I'll add looking for an enabled menu item on the list of things to try. That is an elegant solution if it works!

Thanks again, by the way. This is far and away the most useful and responsive forum I've run across.

(As a quick caveat, this is all part of an effort to script an app that does all it can to be unscriptable. I badly need the automations for my work. But I also talk to the developer from time to time and have "gently" been suggesting that the app really needs a nice API. I'm thinking that if I keep posting videos of ugly automation workarounds on the app's forum some day he might see the need. He's a good guy, and the same basic approach got him to add a custom URL scheme, so fingers crossed...)

What's the app?

LiquidText. It is far and away the best solution that I've found for interacting with text (PDFs) in a serious way, which is why I find this worth the effort.

My workflows often involve digging into stuff in LiquidText and then extracting and linking to notes/images/extracts etc. from Obsidian. But out of the box everything is built around moving the mouse and clicking here and there. While there are (finally) a restricted set of keyboard shortcuts, it is not uncommon for a simple, repetitive task to take half a dozen clicks in different locations.

The good news is that they are capable of listening and their development turn around cycle is fairly rapid. The less good news is that they have yet to fully embrace the idea that automations and integrations done out of house are a good thing.

1 Like

I will add that not being able to get the location of the text cursor on a Mac makes the problem much harder. For example, when you tell LiquidText to open a comment box, it rearranges the screen to suit the new addition. That is well and good, except that there are menus that can only be opened by clicking on the comment box. There is a text cursor in the box, but the mouse cursor is wherever it was in the first place. I've played with dropping things like :nerd_face::nerd_face::nerd_face::nerd_face: into the comment. That makes it possible to find again with ⌘F, but since the font size depends on window zoom it's useless for found images. If I could get the position of the text cursor I'd be all set, but for whatever reason Apple seems to keep that information well and truly hidden. I've tried UI scripting, but that turns out to be hopeless.

Why does anybody write an app that is all about user interaction and NOT include an API?

Because they're ignorant and/or lazy, and because the vast majority of users have no idea of what an API is or what can be done with it.

It's horrifying how few users know what it's like to turn a multi-minute or even multi-hour job into a macro that runs in a few seconds or less...

1 Like

If you are interested, here is a video of a macro to take selected PDFs in DEVONthink and import them into LiquidText.

Indeed. I've always seen a Mac as a really nice windowing system on top of a Unix box, so have always made heavy use of the command line to automate where possible. I never was a big fan of Automator, but when I discovered Keyboard Maestro my world got much, much better!

I'm curious. How many people sell their services writing for-the-purpose macros for people? I'm not interested in the job (other than for the occasional client), or getting someone else to do the work. But there have to be uncounted thousands of people who would benefit if they knew what was possible, and if they didn't have to come up the learning curve themselves.

Turn off the 'Display' checkmark in the found-image action after you've gotten things working. The macro will run a bit faster.

I know, but seeing the green box popping up to make it clear what is happening furthers my ulterior motives. :wink:

1 Like

Shameful that the dev is depending upon the spinning pizza cursor and doesn't provide an actual progress dialog.

1 Like

To be fair, I'm pushing it hard. Those crop up when importing a half a gigabyte PDF. I bring books into LiquidText, and sometimes the only way to do the conversion is with screen grabs and OCR. The results can be huge. I suspect that most people never see such a thing.

1 Like

I don't believe that's Apple -- it's the application's responsibility to reveal such things, either directly or via Accessibility. See BBEdit for how it could be done, but there's a difference between the insertion point in a document and a UI widget...

This seems to be a known Apple thing. Here is an old post from 2014 that talks about it: Get text cursor position.

It's possible that the situation has changed. @ccstone Do you have any insight here?

Again, not an "Apple thing". The OS has no "knowledge" of the position of the insertion point -- that's an application or document property. You can get the position if the app allows such via its own APIs, but that's unfortunately uncommon -- even in Apple's own apps (Grrr! And that is an "Apple thing".).

1 Like

Hey Guys,

At some level the macOS knows where the cursor is – that is to say when established APIs are used and Accessibility is properly implemented.

I believe it was @CJK who posted some pretty esoteric AppleScript UI-Scripting code that got the cursor location (not mouse) in some quite unexpected places.

His code may or may not have needed the speech API to be turned on – I can't recall – and I'm not going to spend time fishing for it.

The upshot of this is that Apple could do much better IF they wanted to.


1 Like