I'd recommend AppleScript where possible, then System Events and GUI scripting, only then - "Found Image". And as your very specific case - the suggestion of @kcwhat and @JMichaelTX.
And also a little bit more respect to the developer.
Though I think KM is a brilliant piece of software (as I'm sure many people here with months of time saved - see the cool feature in the menu "About KM"), it is not absolutely universal for any possible needs. It does what it designed for at 150% and thanks to @peternlewis it is constantly improving. It may happen that KM will not cover your case, but it says nothing about the quality of this software, just about your case and your expectations, sorry. Hope you'll solve your problem and interested to see your report on that.
Fair enough, and 100%... I'm going to revamp my macros with KC's method. If it solves the issue (which it sounds like it will) than absolutely, I'll update and acknowledge that the issue was me not understanding KM well enough yet.
And I don't disagree, I've put a month of hard labor into automating what I can. While it's been frustrating watching KM come to a grinding halt, I'm sure I projected some of that frustration toward Peter without understanding that there are multiple ways to use the found image action...
Appreciate everyone's suggestions so far as well. If things go as scheduled I'll be updating this thread some time over the weekend once I've had time to tear through a good 1/3 of the macros I've created. Considerings things only got really rough in the last week/week and a half, it seems like I should see a big drop in the plist size, and some recovered snappiness by then...
Thanks again @kcwhat. Really appreciate you setting things straight. As I've said this seems to explain the enormous plist size. Cheers!
There are many ways Keyboard Maestro could work such that a larger database of macros could be supported. It could be an actual database instead of a plist for example.
But there are also consequences of these changes, and not just in my development time. Cache coherency is one of the hardest problems in computing. In fact there is a standard software developer quote “It’s often said that only two things are hard in computer science: cache coherency, naming things, and off by one errors.”
If the images are stored separately, then that will have a flow on effect on how syncing works. And what happens when the image goes missing, or is changed underneath Keyboard Maestro, and so on.
Yes, the monolithic plist has draw backs when folks start pushing Keyboard Maestro well past what it was designed for, but it also has advantages in other directions.
No problem @jackrabbitslim. Another move, that I made, was to use the built-in KM Icon Chooser, for my Macros bin icons, instead of trying to be so customized (aka cute) with my own pngs. At first, I just wanted to customize everything because I could. After you learn that speed wins, the behavior is modified. The good thing is you are learning early, in your Keyboard Maestro journey, so you won’t make those decisions. YMMV.
Definitely agree with that, that was the assumption I made... I can see it being useful for self containing a macro, but if the risk is creating a plist so big that the editor eventually has difficulty parsing it than seems like that would be the most headache free default....
That seems easy enough to solve: Add a folder "Image Sync" in the same folder where the main KM sync file is stored.
You do the same thing now if the user delete/changes the image file on the Mac where the file option is used in the Action. Doesn't the current Action fail when synced to another Mac which does NOT have the file?
To be clear, this request is NOT asking for you to change any other KM design other than how found images are stored.
FYI I followed KC's method and scaled every macro back by using the file option instead of embedding images within each macro. My plist went from just over 200 MB to 6.5 MB. KM is not longer laggy, in fact I forgot how snappy it was!
So far all the macros are working consistently, and they run faster...
I also wouldn't say I was trying to push KM to its limits, I just had a lot of redundant screenshots... For example if I have 50 macros that do the same thing, (load an instrument), however the specific instrument is unique in each macro, I wasn't just using the data required to store the screen shots required to run 1 version of the routine 50 slightly different ways; because I assumed KM was linking to the image I wound up eating 50x the data needed because I wasn't doing things properly.
Having very little programming background I didn't use subroutines/execute a macro like I should have initially... Now every macro references a subroutine wherever possible, and all images are linked instead of embedded. One folder of macros alone shaved off somewhere between 40-50 MB.
Anyway, my apologies to @peternlewis for being a jerk. I had no idea that KM converted each pixel of the image to code by default... Either way everything's running like a well oiled machine and I'm glad I got the growing pains out of the way early on....
I would submit that this is NOT an unusual use case. From what I can tell in the Forum, many users use the various Found Image actions. AFAIK, KM is the only Mac automation tool that does this. So, when users discover how great it is, they tend to make great use of it. I know this is true for myself, even though I try to make found image the solution of last resort.
This is the sole feature that lead me to KM. I'm not being even slightly hyperbolic by saying this either...
KM was the only application that would solve the issue of automating repetitive tasks in an application (Logic), that has various parts of the UI where shortcuts aren't available, and the state of the UI element you want to change is variable -- meaning coordinates do not work. (For example - a Slider, a Knob, a view that may not always be in display, or a view or object can be 'floated' and may not always exist in the same location, etc).
TLDR: KM is the only thing that allows me to automate repetitive UI-based tasks in an application where many repetitive actions require a ton of unnecessary mouse clicks, dragging, etc, because the application does not have a shortcut for various common functions.
Not to mention this has lead to a huge improvement regarding carpel tunnel. So much so that it's more or less not an issue anymore...
Basically image recognition is what appealed to me, and I can pretty much guarantee it's the same missing link that has attracted thousands of other media composers, dialogue and post-production editors, etc to KM. Unfortunately editing programs typically have many limitations that require clicking and dragging on various UI elements.