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:
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.
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)
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)
(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 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.
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.
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.
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.
As this project has evolved, polling is less a concern - my AppleScript daemon is happily chugging away. I wonder how one would actually measure it's 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 wish list 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.
@avialan this is incredible - I'm in the process of trying to build a floating status window with some system information. If you could share the code you already have, that would be awesome.
Why thank you Aktariel. And how timely. I've really been wanting to revive this project.
Since I wrote it, KM's floating html prompt has gained many capabilities that would make the whole thing a lot cleaner. I'm deep in another project right now, but making myself a task to get something posted here within a week. don't be afraid to ping me if I drop the ball...
"Infloatainment"- as I came to call it - has an extendable 'plugin' architecture, making it easy to add modules which could monitor many things besides Finder selection - the clipboard, network traffic, the output on my solar panels...
Stats can be grouped into sections, with a disclosure triangle to hide the group
Lastly - one reason the project became less relevant was realizing that Finder had selection-stats-monitoring built-in long ago, that I'd never discovered - in the "Preview" pane. (Command-Shift-P)
