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:
-
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 welcome your thoughts.
Avi