@peternlewis - I know the chances of this are slim to none, but you've surprised me in the past many times, so I thought I'd ask. It's possible that I already asked for this before, and if so, sorry for the repeat request.
Is there any chance you could add the optional ability for a Custom HTML Prompt to act like other windows? Specifically, be able to Cmd-Tab to them. Having a Dock icon would be awesome too.
I'm under no illusion that this is a simple thing for you to implement. But you're a wizard extraordinaire (yes, I'm butt-kissing). I was reminded a couple of weeks ago about how amazing it was when you added Local and Instance variables. IIRC, we asked for Local variables, you said "yeah, right" (or some such thing), and the next thing we knew, you'd implemented them in a way much more elegant than I ever imagined (including Instance variables). Same with Subroutines. And many, many more things, for sure.
So, if I ask not, I will most likely receive not... so I'm asking.
You can't Command-Tab to a window, and windows don't have Dock icons.
It sounds like you mean having them act like an application in its own right.
That seems unlikely to happen.
There are ways of making Chrome applets I believe, and presumably you could then have an HTML window in it, but I don't know what facilities it provides as far as communications that might allow talking to the Keyboard Maestro Engine.
Yes, that's what I meant (acting like an application). In fact, I was going to describe it that way, but I decided to explain what functionality I wanted instead of assuming I knew how to provide said functionality. If that makes sense.
And I figured you'd answer with something like that. But I also just wanted to put the idea in your head, and let it ruminate. You never know what ingenious solution might percolate to the surface.
Personally, I had been thinking KM could have a seperate application that you'd spawn, which hosted the prompt somehow. That application would provide the Dock icon, and assuming the Prompt window could be created in such a way as to be a "real" application window, it would also solve the Cmd-Tab issue.
But since I've never been a Mac developer, I have no idea if that's even feasible. Anyway, thanks for listening.
Take a look at Platypus, which "creates native Mac applications from command line scripts such as shell scripts or Python, Perl, Ruby, Tcl, JavaScript and PHP programs."
Interesting, thanks for the link. As it stands right now, I need to interface with KM, so it probably wouldn't work for me, but it's something to consider.
Thinking sideways (and completely without trying!) -- you could, perhaps, use osacompile to write a stay-open AppleScript app every time you opened an HTML Prompt, and run it as part of the macro. The app's functions would include "when I'm activated, bring the HTML prompt I'm responsible for to the front" -- that may be all it needs. When you dismiss the prompt you Quit the app and delete it.
Yes, but would you be able to Cmd-Tab to it if it didn't have a window? Oh, I just tested it with BBEdit open but no windows, and it does show up in Cmd-Tab, so maybe it would work.
But even it it worked this would be an awkward solution...
But possibly worth a try. Unfortunately, I'd have no idea how to write said AppleScript app... ;p
--------------------------------------------------------
# Auth: Shane Stanley
# dCre: 2016/08/29 04:19 +1000
# dMod: 2016/08/30 03:54 -0500 CDT
# Appl: Miscellaneous
# Task: Idle Handler Example
# Libs: None
# Osax: None
# Tags: @Applescript, @Script, @System_Events, @Idle, @Handler
--------------------------------------------------------
(*
--------------------------------------------------------
From : Shane Stanley <sstanley@myriad-com.com.au>
Subject : Re: Exiting an app with an infinite loop?
Date : August 28, 2016 at 18:19:47 CDT
To : AS users <applescript-users@lists.apple.com>
--------------------------------------------------------
On 29 Aug 2016, at 8:03 AM, Barry Wainwright <barryw@me.com> wrote:
Would an ‘on idle’ handler be better here than a repeat?
Yep.
*)
on idle
tell application "System Events" to set myApp to first process where it is frontmost
tell application "BBEdit"
activate
-- Magic Happens Here
end tell
tell application "System Events" to set frontmost of myApp to true
return 600
end idle
on quit
continue quit
error number -128
end quit
--------------------------------------------------------
As I think you've found out by now -- it's just another app, and you can switch to it in the normal way whether it has a window or not. I'm hoping that Chris already has a handler that'll on activate or similar to fire an event back at the KM Engine, but if we can't get that to work you could have a KM macro triggered by "Any app activates" that used the app name to pop the appropriate HTML Prompt -- a bit kludgy, but you work with what you've got...
I think this is a blow-out. All Engine windows have an index of -1 which you can't change, you can't activate them individually, you can minimise them but you can't then unminimise them... I'm fresh out of ideas, I'm afraid.
When you activate an Engine window it is always the most recently frontmost that is brought to the front again. So If you only have one HTML Prompt open, an AppleScript will work. Bonus -- because you don't need to refer to a window id you don't need to capture it for the AppleScript and so you don't need to compile the script on the fly.
So save this as a "Stay-open, no startup screen" AppleScript application called "testApp.app" on your Desktop:
on idle
if frontmost of me is true then
tell application "Keyboard Maestro Engine"
set winCount to count of every window
if winCount > 0 then activate window 1
end tell
if winCount = 0 then tell me to quit
end if
return 1
end idle
on quit
continue quit
end quit
You should be able to switch to another app, covering the HTML prompt, then switch to "testApp" and have the prompt come to the front. And when you close the prompt "testApp" will auto-Quit when it is next frontmost. You could also add a Quit action to the macro -- I left it out so you could see the the self-quit behaviour -- and because it's an app you can also right-click Quit on its Dock icon.
If I'm on a different desktop, it does switch to the correct desktop, and the HTML window is visible, but then another app's window comes to the front.
It doesn't seem to want to auto-Quit.
On the plus side, it does the thing I need the most: It lets me bring the Custom HTML Prompt to the front. I may need to change the applet to look for a specific window title, which is OK by me. I can have a separate app for each prompt I'd use it for - I assume I can change the icon, so I'd change it to something appropriate for each prompt.
If turning off the start-up screen didn't fix that, try adding an empty run handler:
on run
--do nothing
end run
Desktops/Spaces -- I'm afraid you're on your own there. More trouble than they're worth, IMO.
It should auto-Quit when a) it is the frontmost app, and b) there are no Engine windows (of any kind) open. A quick test shows that that includes palettes, which may be what's stopping you.
If you're using window titles you can get round that with something like this, for a window named "My HTML Prompt":
on idle
if frontmost of me is true then
tell application "Keyboard Maestro Engine"
set winNames to name of every window
if count of winNames > 0 then activate window 1
end tell
if winNames does not contain "My HTML Prompt" then tell me to quit
end if
return 1
end idle
If you're happy keeping an app per Prompt that should work -- you could even move the quit line to below the if block, above the return, so it would quit without needing to be brought to the front first. I guess it'll depend on your workflow whether it's better to check window names only when frontmost or to check every second regardless.
