Feature Request: Option for Custom HTML Prompt to Act Like Other Windows

@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. :slight_smile:

2 Likes

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. :grin:

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."

2 Likes

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.

1 Like

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.

3 Likes

That's an interesting idea, but I think it would need its own window in order to be able to Cmd-Tab to it. But it's something to think about - thanks!

Not really. AppleScript apps can run without windows.

It could have an idle handler that would notice when it was frontmost and then call the HTML prompt.

But even it it worked this would be an awkward solution...

1 Like

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

1 Like

Save this as a stay-open AppleScript applet:

--------------------------------------------------------
# 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

--------------------------------------------------------

Change the nuts-and-bolts as desired.

2 Likes

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...

2 Likes

Uh, thanks, but I wouldn't know what to change to bring the Custom HTML Prompt to the front, although if it's "Stay on top" then it wouldn't matter...

Okay, I don't know either... :sunglasses:

1 Like

You are a devious fellow.

2 Likes

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.

1 Like

On the other hand...

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

...and then run this macro:

HTML Prompt Test.kmmacros (2.3 KB)

Image

(ignore the shonky HTML...).

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.

2 Likes

Thanks!

Very close.

  1. It displays this prompt when the app starts:

2023-02-22_15-53-10

(I'm on Monterey 12.6.3)

Once I click Run,

  1. 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.

  2. 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.

Did you turn off “Show Startup Screen”?

image

Yes, I just found out about that, and I did turn it off. I also found out how to change the icon.

1 Like

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.

2 Likes