Hi Peter & others
What would it take to get a trigger for "Finder Selection Changed" ? Of course this event occurs a lot! so I appreciate the overhead could be prohibitive.
Alternatively, I can poll Finder (with AppleScript) to track its selection. Again overhead - how heavy a load if I set that running in KM, say a few times / second?
the goal is to dynamically display info about the current finder's selection. to feel responsive, the display needs to track the selection within .2 - .4 seconds.
thank you!
thanks for your thoughts. after I posted, it occurred to me that KM's nearest comparison to that kind of monitoring is the trigger on change of clipboard.
I went with an AppleScript daemon (not in KM) polling every .5 second and I can't detect any lag on an MacBook air M1. FYI, code snippet is below.
this is for a project I described here which shows info about the finder selection in a custom floating html prompt. It's quite responsive, even deep querying info about image files. (adding a screen movie now). Maybe you underestimate MacOS's ability to keep up!
(1st time posting code here, is this ok?)
on idle -- watch for changes in finder selection
try
set allsel to application "Finder"'s selection
on error
set oldsel to {} --bail
return 0.5
end try
if allsel is not oldsel then -- selection has changed
getstats(allsel)
set oldsel to allsel
end if
return 0.5 -- did you need that cpu for anything important?
end idle
on getstats(selectedFiles)
set sizeString to ""
set picDimensions to ""
set compressionratio to ""
if length of selectedFiles > 1 then -- multiple items selected. compute total size.
set sumtotal to 0
repeat with aFile in selectedFiles
awakening an old thread - I don't suppose this situation has changed on KM's side - no "finder-selection-changed" trigger?
I just wanted to share that 1) it's an incredibly powerful capability, and 2) I totally understand any dev not wishing to run the gauntlet of app entitlements, permissions, OS Security, and User-handholding to actually get it working.
But I did build a Mac app which in fact follows changes in the finder's selection. With this info, and a floating window, it can add an "inspector panel" to the finder. A quicklook plugin would do the same thing; I recommend that over my solution if possible. But I can't do QL because I want to display info for image files, and apple seems to override any QL plugins for "core" types like images.
The solution is incompatible with app sandboxing, IE can't be in an App-store app. So I created 2 versions of my app - only the non-sandboxed / direct download has the Finder observation feature.
Demo Time: Specifically, it displays AI Image-Generation Metadata - things like the text prompt used, and all the model settings - which may be attached as image tags. In this video, it's actually running alongside the quicklook window, as I browse a folder of images - using arrow keys to navigate & select files.
Implementation details. Happy to share lessons learned. I'd open source this / publish a swift package if asked. In the end, the app does basically what the above 4 yr old AppleScript did. It actually polls, firing off a short AppleScript querying the finder of its selection. Performance isn't an issue - it can poll often enough to feel quite responsive.
