Focus Stolen When KM (10) Launches Faceless App / Driver

One of the many edge cases I've used KM to solve is my Wacom tablet driver partially losing connection to its OLED button label displays on sleep / wake.

So I have a KM macro that on wake quits the Wacom driver, waits a few seconds, and then relaunches it. Which works splendidly, except...

When the driver relaunches, even though it's not a GUI app and has no windows etc of its own (it lives in a hidden folder etc), focus is lost from the foremost window I'm in. It doesn't appear to go to anything - I'm remaining in the same application, focus is just lost from the current window / what I'm doing.

So if I'm in the middle of typing in iMessage, suddenly the input field isn't receiving keystrokes, and the computer is beeping because I'm issuing meaningless unmodified keyboard commands.

I've tried the Open command with Finder as the operator, and I've tried the Activate command on the driver app directly.

Would the checkboxes for Activate, or the If already at the front: droplist make any difference?

Or is there a better way to solve this?


This light help…

Try adding a Pause and Activate Last Application actions to your macro.

Consult the KM wiki here: action:Activate Last Application [Keyboard Maestro Wiki]

1 Like

Would Activate Last Application work? The problem isn't taking me out of the application itself (the application menu doesn't change), it's just defocussing all windows in the current application.

There’s only one way to find out…

What do you mean by that - what is triggering the macro?

And by the sounds of it the focus goes somewhere else.

Here's the workflow:

The shifting focus is odd, because it's not going TO something else specifically - the current window, regardless of what app is open, is just de-focussed. My suspicion is it's a symptom of launching something that doesn't have any user-facing UI.

You’ve presumably seen this which is why you’ve come up with your workaround:

Looking at your workflow you seem to be directing focus to the Wacom driver. Since you’re not keen on trying my suggestion I’m afraid there’s not much else I can help with.

that's not actually the problem - the tablet stays connected, and all its input functions work, it's just the OLED displays (which only this model has) which act as dynamic labels for the buttons which fail to wake.

I'm happy to try the suggestion, I just wasn't sure of the logic of it, because I don't appear to be leaving the foreground application when the macro is run. Its foremost window is deselected, but the active application name in the application menu doesn't change.

What I would expect to happen therefore is something like

Using: Safari
Switch to: iMessage start typing
Macro fires off.
Last Application switches me to Safari...

Unless what I'm seeing is some strange state where I'm not actually in iMessage, but the driver has not taken over the menubar, so I'm seeing iMessage's ownership of it while it's a background application.

I'll try it out overnight and see what happens for the next sleep/wake cycle.

Otherwise I imagine I'll have to investigate if there's a way to explicitly launch as a background process?


No logic - just a hunch.

No need to wait: just add a hot key trigger to your macro (so it'll run at wake or with the hot key) and then, when you're in iMessage use the hot key to trigger it and see what happens.

Like this for example:


So I ran this workflow:

And no change to the behaviour:

  • System woke with Finder as the foremost application.

  • I switched to Messages, whose sidebar became partially transparent with the desktop background colour, and the cursor began flashing in the text entry field.

  • The tablets OLED screens all came to life as the driver relaunched.

  • The Messages window lost focus, sidebar turning opaque and cursor disappearing from text entry field, while Messages remained the named application in the applications menu.

I think I'm going to experiment with setting the driver Quit to a sleep trigger as a separate action, and just launch the driver on Wake so I can avoid the problem, unless there's a known way to launch something in the background that won't steal focus?

You can try the advice given in this thread.

Yeah, it looks like they're experiencing something with a similar root cause...

What I suspect is needed is an Activate Last Window action, because even if KM is switching back to the application, it isn't returning focus to a window - so you have to manually click a window, even if it's the only one the application has, to get it into a position where it can receive input.

So I came up with a solution that was more about avoiding the problem...

I tried changing the script to quit the driver on Sleep, and relaunch on wake, but that didn't work - it appears the fix for the Wacom driver requires a full quit / launch cycle post wake.

I'd previously had a 20 second delay in there, so the quit/launch didn't interfere with the login process after sleep, but decided to see if that could be discarded:

So the whole thing runs successfully before my main screen has stabilised from waking up, ready for me to log in.

Problem solved, I suppose. :person_shrugging:

1 Like