I'm using Custom HTML Prompts more and more these days, and since they don't show up when Alt-Tabbing, they can get lost sometimes. So I want to make a macro to go directly to a specific one, if it's open.
Can you think of a way to:
Find a specific Custom HTML Prompt (probably based on window title), no matter what desktop it's on.
Switch to that desktop (is that even possible?) If not, I can deal with that as long as I know what desktop it's on.
Once I'm on the correct desktop (regardless of how I get there), I'll want to bring it to the front.
Well.. I'm not really the one to ask on this one, because I hate pretty much everything about Apple's implementation of Desktops – and I only rarely use them in a very limited fashion.
That said – I've spent a lot of time investigating same for various users over the years.
System Events cannot see into desktops that are hidden – only the current one – so that option is out.
Something like this would normally work, but it seems to fail with the Keyboard Maestro Engine – at least with a test Text-Display window.
tell application "Keyboard Maestro Engine"
name of windows
end tell
Hopefully some code that @CJK wrote can come to the rescue:
ObjC.import('CoreGraphics');
let wInfo = $.CGWindowListCopyWindowInfo(16, 0);
wInfo;
This is one of several reasons why I abandoned KM's Custom HTML Prompts long ago in favor of making my own HTML prompts, which I have KM macros open in the browser of my choice. Each such page (prompt) then loads KM variables before being closed by the macro. But the prompts are as findable as any other browser page. (Actually, in most cases, I also have a KM macro build the HTML before opening the prompt/page.)
I use them to load KM variables and then proceed with the given KM macro. I do this by having the browser page (my HTML prompt) load the clipboard with all of the various element values (dropdown, etc.) from the page (delimited any way I like, via Javascript). Then KM simply processes the clipboard to load various variables, based on my delimiting. As for GetVariable, I pass variable values to the HTML page simply by having KM write a skeleton HTML that includes variable tokens in the text that gets written to the HTML page. That way, the HTML that gets written depends on the current values of the variables whose tokens I use in the Write action to produce the page. So, a macro has the form:
Perform some number of preliminary KM actions;
Write text to file (skeleton HTML with variable tokens that get processed when writing);
Open HTML file in browser;
Interact with HTML page;
Page retrieves values via Javascript and copies them to the clipboard;
KM processes the clipboard to retrieve the values and load KM variables;
Perform the remaining KM actions.
Thanks. It sounds like a great solution to many situations.
But it won't work for most of my Custom HTML Prompts, which require interaction with KM, such as Trigger. The Triggers need to happen with the prompts running - many of them actually return values back into the Prompt using Run Javascript in Custom HTML Prompt, along with async routines on the Prompt side to wait for the data and process it.
Try with a whose clause. @DanThomas , if you've a unique window name then eg
tell application "Keyboard Maestro Engine"
return id of every window whose name is "My Unique Name"
end tell
...will get you the id of the engine window titled "My Unique Name". Like Chris, I'm not a Spaces/Desktops user so couldn't tell you if pumping the result of that into a "Bring Engine Window with ID..." action would do the trick.
@ccstone -- it's kludgy and there's probably a better way, but I'm getting "every engine window" with
tell application "Keyboard Maestro Engine"
return every window whose name > ""
end tell
As I said, I don't use Spaces. I thought you meant that your snippet didn't work generally in KME, which surprised me because I thought we'd both used it successfully before. So I tried it and it indeed failed, so I fell back on the whose kludge.
And now I try it again and it's working. Sunday brain fart by me, I reckon.
set kmInst to system attribute "KMINSTANCE"
tell application "Keyboard Maestro Engine"
set _windowName to getvariable "Local_windowName" instance kmInst
get id of first window whose name is _windowName
end tell
Then I wrote a macro that loops through all my desktops, to see if the window is on any of them. If it is, the macro brings the window to the front. Otherwise it returns to the desktop I had open previously.
The process of determining which desktop I'm on, and how to switch to other desktops, is the subject for a different topic. But here's an image of the macro:
Alternatively, the following is for current desktop
This will list all windows of Keyboard Maestro Engine
tell application "Keyboard Maestro Engine"
set windowTitles to name of every window
set titleText to ""
repeat with w in windowTitles
set titleText to titleText & w & return
end repeat
return titleText
end tell
This will set focus to window "myWindowTitle" using Applescript only
tell application "System Events" to tell process "Keyboard Maestro Engine" to perform action "AXRaise" of window "myWindowTitle"
But if anyone can share the AppleScript to check if any window of Keyboard Maestro Engine is in focus, that will be wonderful. I try many "solutions" on the net on checking focus but none of them work.
I work mostly in JXA, and I tried to get the AXRaise action to work, but it didn't. I may have done something wrong. But fortunately the method I chose works.
I have no idea how to check if its focused. When I look at the window in ScriptDebugger, I don't see a property like "frontmost" or anything close.
And my first name is "Dan", not "Thomas". No worries though - I've lived with two first names all, my life.
set AppleScript's text item delimiters to linefeed
tell application "Keyboard Maestro Engine"
return (name of every window) as text
end tell
You do have to be mindful of AppleScript's text item delimiters (TIDS), because they do change the way text items are seen by AppleScript – it can trip you up if you forget that you've set them.
For a one-off script like that above the form is perfectly safe, but for normal usage in larger scripts it's a better practice to do something like this:
set {oldTIDS, AppleScript's text item delimiters} to {AppleScript's text item delimiters, linefeed}
tell application "Script Debugger"
set nameList to (name of every window) as text
end tell
set AppleScript's text item delimiters to oldTIDS
return nameList
And the “focused” property both come up false no matter whether the KM window is focused or not.
If you really want to know about this then ask on the Script Debugger Forum and see whether the Window Manager as accessed by AppleScriptObjC can shed some light.
The alternative AppleScript you provided is very good.
As for focus issue, I wonder why detection of KM Engine window's "focused" property using AppleScript didn't work. I suspect it is because the property only work for those applications that change the menu bar.
You could be right that AppleScriptObjC might help. I try the Script Debugger Forum then.
