Pushing the Limits of the Custom HTML Prompt Window

[avialan]

Hi KM wizards,

I’m working on a floating info window displaying stats for the current Finder selection (see prev posting- I settled for a headless applescript app to poll Finder selection). I’m ‘auditioning’ the custom floating HTML window for the job. It was super easy to get up & running, but I’ve hit enough roadblocks to reconsider. I may be pushing its design - maybe it’s happier filling out forms, not modelessly dallying around, displaying environmental info.

The good news: - I haven’t come across another utility that let me create a floating stats palette so effortlessly.

The issues, by priority:

1. It doesn’t float “high” enough. KM palettes float above Finder’s QuickLook window, but custom floating HTML does not. Bug? I use QL constantly, and my stats keep dropping behind it. And when I bring it front, keyboard focus gets confused. I have to bring it front, then click back down to a Finder window.

2. My headless Applescript applet updates the stat window on idle. It could almost write to the page with “do javascript in…”. But "in" what? If KM could give me a handle to that window which I pass to “do javascript”, that’d be amazing. my applet could go right in & update
   (Workaround: route updates through KM: set variables, then call KM’s doscript for a macro which executes Javascript in the custom HTML window. circuitous & awkward to debug)

3. Notify it’s closed (to stop polling Finder, etc) - an async callback in KM when the window is closed would be easiest. i set a window event listener for the “unload” message, but it’s never called. (perhaps KM wants window closed with a form SUBMIT)

   (Workaround: KMWillCloseWindow, which calls back up into KM to execute a macro. extra steps/awkward)

4. (Bonus item) – I see that “Execute Javascript” is a rare command that doesn’t interpret KM’s tokens - only string literals. I wouldn’t be surprised if this is a deliberate security limitation. but still would be nice… my workaround is the daemon stashes some JS in a KM variable, that the stat window retrieves and executes. (Do not try this at home. (Or at work..))

Overall many aspects are great - like running full JavaScript in the window. For instance, my click event listener rotates through display modes by just clicking anywhere in the window. CSS reacts to the contents. And being able to drop into the full web developer tools, with breakpoints, variable values, etc. is amazing.

Lastly, (extending an already too-long post) I’ll mention that KMs palettes themselves were close to what I need. Though lacking in fine UI control, they’re solid in most other ways. I tried using macros as display elements by changing their names. the dealbreaker: latency. It takes up to 1 second after changing a macro’s name for it to reflect in the palette.

I welcome your thoughts.

Avi

[JMichaelTX]

@avialan

Hi KM wizards, I’m working on a floating info window displaying stats for the current finder selection (see prev posting - I settled for a headless applescript app to poll finder selection). I’m ‘auditioning’ the custom floating HTML window for the job. It was super easy to get up & running, but I’ve hit enough roadblocks to reconsider. I may be pushing its design - maybe it’s happier filling out forms, not modelessly dallying around, displaying environmental info.

I hope you don't mind that I have revised your topic title to better reflect the question you have asked.

FROM:
Abusing the custom Floating HML prompt window

TO:
Pushing the Limits of the Custom HML prompt window

This will greatly help you attract more experienced users to help solve your problem, and will help future readers find your question, and the solution.

I don't see any "abuse" -- just an attempt to extend the HTML Prompt.

[avialan]

For whomever might be interested, I'll post code on request. Here's a screen movie demonstrating some wins / losses. It's plenty responsive, polling Finder's selection every .5 second. I don't sense any slowdown on my mac.

• It reacts quickly to current selection, as it queries image file stats.
• It shows cumulative size of multiple files selected. which Finder should just do.
  (Finder "preview" pane can show cumulative size of selection but I don't use that)
• I also tried using the top 2 KM macro buttons to show stats. See that they're about 1 second behind in updating.
• Sadly, finder's QuickLook Window slices in front of floating html prompt.

.

[ccstone]

Hey Avi,

Well done!

-Chris

[JMichaelTX]

@avialan

For whomever might be interested, I'll post code on request

Thanks for sharing your video demo.
Please do post your code. I'm sure many will find it useful.
May @peternlewis could even figure out how to use it to create a new Macro Trigger: On Change in Finder Selection.

[peternlewis]

Triggers wont work if they require polling since they cause unacceptable CPU & Energy usage. If there isn't a notification of a change, Keyboard Maestro won't have a trigger for it.

[avialan]

Hey Peter
thanks, I’m not surprised. As this project has evolved, polling is less a concern - my applescript daemon is happily chugging away. I wonder how one would actually measure its drag on the system. I’ll presume your clipboard trigger is from an OS notification?

My bigger issue is the restricted communication to the floating window, and getting obscured by Quicklook, as mentioned.

And a wishlist item - a window so small would be nice to drag it by clicking anywhere in the window, or with a modified click. I just found this tip about enabling that systemwide with ctrl-cmd-drag. (tldr: defaults write -g NSWindowShouldDragOnGesture -bool true/reboot). It works great.