On and off for several years now I have struggled to identify a key sequence, or script that causes an app's windows to be (1) displayed, (2) in focus, (3) on top.
So far I have failed. The 'show application windows' sometimes seems to do something, but there are other times when the menu item 'show all' will raise the application's window even when this command does not.
I am willing to be arbitrarily hacky to achieve this goal. But so far even this low bar goal has been a fail. The best I have now is a script that attempt to raise an app, then it KILLS the app and reactivates it. This kinda works, but it is dangerous, and is usually un-needed, since I often can manually get the app to raise, even when the scripting I have done fails me.
yes, that's right. In many cases 'activate application' does work. But there are cases where it systematically does NOT do the same thing that going into the windows menu on an application and explicitly selecting a window to activate.
Also using 'alt-tab' to raise the application will work in cases where 'activate application' does not.
I would be very surprised if I were the only one having this problem, as it is a frequent failure mode for me.
NOTE: I have a keyboard macro to 'hide' current window instead of minimizing it. This might have an effect which is different than others? (but in any case, I would love a macro that activated ALL window states)
P.S. I would be fine creating an applescript... whatever it took to have a ACTIVATE_DAMMIT script that just always works. Just not sure how to do it.
Hi, @DanO333. Yes, this seemingly simple task is surprisingly elusive. I've found that it is even more difficult when the app in question is already running in a different Mission Control Desktop Space.
I've shared a set of macros in Desktop Spaces • Macros to Improve Navigation and Window Management. One macro in the set is: sub—Activate an App and Wait Until It Is Ready. My goal was to create a subroutine that could be used for any app regardless of its current state, i.e., not running, running in current space, or running in another space.
Although this sub may be more complicated than you need, you might want to give it a try. For your convenience, I've pulled it out of the set and uploaded it here: The following is v1.2 (modified 2022-07-12) and, for the time being, one version newer than the one included with the Desktop Spaces set mentioned above:
Note: After downloading a reviewing this subroutine, you'll see that the app activation is fairly straightforward—notwithstanding the Finder which requires some unique actions. Ironically the app activation verification is more complicated as some applications don't follow long-standing macOS standards. The embedded complication is worth the effort, however, as many macros will fail if subsequent actions run before an application is fully ready.
Jim, I can tell a lot of PAIN went into writing that script.... so so painful to even look at!
I have written your broader script for every OS I have used... I even have a much weaker one, I wrote for the Mac.
Indeed I prefer your more comprehensive script, than the more limited Activate application command. (I use single key stroke for all of my major apps, and it is great to use this sub routine instead of the K-maestro version.)
I tried it on one app and it worked as far as I can tell, and it was snappy too in the case that the app is already running! If I find issues with the script, I will let you know just in case you are trying to harden it. I feel like such a capability would find great value for others too, but few will even know about it. K-maestro needs a better plug-in ecosystem.
I have found that instead of using the KM Action Activate Application to do this, using the KM Action Open with the path to the App and "with Finder" selected works to bring the Application's windows to the front consistently even when the App's window has been minimized or hidden. Here is an example with the Mail App but it works with all Apps.
If the App is already running it simply brings it to the front.
Hi @Zabobon. Yes, in cases when the application can be hardcoded, I've done the same thing–although I've not tested this approach with as many applications as I have with the subroutine I shared above.
With the subroutine, the application can be specified at run time. Of course, as in the example call, it can be effectively hardcoded.
The subroutine also confirms that the application has been activated.
Hi @_jims - just for completeness, I also use this in Subroutines where the path is in a Variable or even better in a Dictionary. I know you like dictionaries
One advantage of the approach used in the subroutine is that the path is not necessary, just the application name.
One note with the above image:
Please don't be confused by the name of the comment action. It makes sense in the context of the entire subroutine, but does not apply to the three subsequent actions shown in the image.
Thanks Zabohon, I will keep this in mind if _Jims script fails me. (it is nice to only depend upon KM itself).
I have updated all of my scripts to use _jims script... it seems to be working well.
I wonder if all apps will respond to the open command in the same way (and force window to the top). I never thought to use it in this way. (I do use the open command to provide explicit arguments to apps.
Where is this v1.2? I am happy to use it. (maybe you create a github GIST with this macro?)
We should convince the KM maintainer to absorb this capability, maybe there would be a flag on the 'activate' command called 'force' which would run a version of this script?
I don't know, but I know other users must need this too!
thanks!
p.s. I have converted all of my scripts over to use this sub-routine. I will let you know how it goes after some time of using it. (so far it seems quite reliable)
p.p.s. Do you think @Zabobon 's approach will work in general? Do all apps act the same when re-opened?
I could, but at this point, I prefer to upload all of my shareworthy macros to this forum.
Thank you!
It would certainly be better to ask @Zabobon who undoubtedly has more experience than me with that approach.
However for things that I do know, please refer to my above reply to @Zabobon's comment.
I haven't seen any differences and I've been using it for several months. Of course, it's quite possible that there could be problems with an app that I've never tested.
As you have a solution that works with @_jims' excellent script I would stick with that. I only mentioned the alternative method I found as, awhile ago I too was finding it frustrating that activating an App wouldn't always restore its window and I stumbled across the method using the KM Open Action. But in answer to your question, yes, I have found it consistently works with all Apps I have used it for.
