How to Reorder If and Until Options

I use If... and Until... structures frequently. Very powerful is the way they allow you to create a list of choices where "any of the following are true".

I've been using these to create macros to do things with Facebook pages, and the list seem particularly useful because Facebook keeps tweaking the UI design. Image matches from a couple of months ago may fail overnight because the font is now a little smaller, etc.

When that happens, I just add another option to the If... or Until... and paste in a new screen clip from the new format and away I go.

EXCEPT, for speed and efficiency, I'd like to insert the new image at the top of the list, so it is found first and the internal KBM logic can then not even bother looking for any others. KBM makes it easy to add a new choice to the bottom of the list, but to insert a new one at the top, is more difficult.

Is there an easy way to edit an If... or Until... list to insert a new option at the top?


No, there is no way to reorder them.

Well, not without editing the XML.

Although you may be able to do it with AppleScript, but I don't think the scripting support gets that deep in to the actions.

1 Like

Hey August,

See this:

KMET: Edit KM Objects as Text (Search & Replace) (incl. Big Sur patch)


1 Like

I'd recommend saving those little screenshots as files somewhere on your drive and having that action look for the image in those files. It keeps the Keyboard Maestro plist file from being bloated with images (since they're stored elsewhere on your drive), and the editor will run smoother over the long haul.

Plus, if you use "screen contains image in file", you can simply change the order by copy and pasting the file paths into whatever order you want.

Perhaps not the perfect solution, but I think it might help you. I made the transition these last few weeks to using image files for any found image actions and it's a lot easier to work with and has helped keep things more organized.

1 Like

Thanks, Peter.

Is there much of a performance hit between matching the first image (say, 100x200px) and matching the 10th image in an "If Any Are True" list?

That's the point of my wanting to add the newest option at the top, my presumption that it's the most likely match going forward, and wanting the macro to execute snapily.

Thanks for the idea of matching file images, Chris (cdthomer). I'm intrigued about how it could make things a little more organized.

Do you have any idea if the macros run faster or slower that way? Does it have to do multiple file accesses each time the macro is run, or does it load the whole set when KBM is loaded, or what? What are the symptoms of "plist bloat"?

As for the copy and paste cycle, that's what I'm already doing. I add a new option at the bottom and them copy and paste each "The Screen: ⇳ contains ⇳ Image:" items successively down the chain until I can paste the new entry at the top. Since the tiny thumbnails all look alike, I keep track of where I am with the Display checkboxes. In my imagination, I don't see copying and pasting pathnames as being substantially faster; I still have to copy and paste each item in the chain.


Thanks Chris (ccstone).

This whole approach looks intriguing, and not just for this problem. I think I want to try these macros out to get familiar with them (when I have some time to play...).

As for my current question, it looks like this can be handled by cutting the new item from the bottom of the list and inserting at the top of the list. That makes the update effort constant, no matter how many items are in the list. That makes it feasible to let the list grow; as long as the most likely item is first, it shouldn't have much performance hit, right?

So if there are only 3 or 4 items in the list, it may be faster to just move things one by one down the chain, but if there are 10 or more it would be much less mind-numbing to manipulate the text version, once I have going into the text in my toolkit.


P.S. Is there a versioning spit? Should the Big Sur version not be used on earlier OSes (I'm staying on Mojave as long as I can) or can the V1.1 version be used anywhere?

When you say:

  1. Delete the macro [KMET Sub-Macro] Get Selected Objects as Text .

I presume you mean the macro named [µKMET Sub-Macro] Get Selected Objects as Text, right?


No idea. I haven't gotten around to trying it out...


I think the Big Sur version can be used on Mojave, but there's no reason to use it - nothing else has changed.

No. All matches will run simultaneously.

So unless you break them in to multiple actions, Keyboard Maestro will do all of the matches. The conditions will abort once the overall condition is met (eg “any of” will complete if any condition returns true), but the match will probably continue to completion before it figures out its decision is no longer required.

Thanks. Is there any performance hit (or advantage) in having the matching image in separate files, as Chris suggested?

This is just my personal experience, and no doubt @peternlewis can correct me and/or expound on it if I’m wrong. But the macros appear to execute slightly faster when using image files rather than using images embedded in the actions(s). Could just appear to be that way though.

But what has been stated here previously (and by people far more knowledgeable than myself) is that when you place an image directly into the image well, it copies that image into Keyboard Maestro’s file system. What this means is that if you have a lot of macros that use a lot of “find image” actions, your KM file (I think it’s the plist file, but again, not 100% certain on the file type) can become very large, causing a general slowdown, especially of the editor. This is because every time you make a change to one macro, the entire plist file has to be updated (since every single macro is stored in one master file).

I absolutely know this last point to be true! Because over the last few weeks, I did a LOT of housekeeping in my macros (I have nearly 1,000), and switched from embedded images to image files. I also deleted a lot of macros I no longer needed (like simple text expansion macros that I can accomplish the same thing with Typinator). This has resulted in the KM Editor running MUCH faster and smoother.

Again, perhaps Peter or somebody else who is very knowledgeable on the inner workings of KM can explain more about advantages/disadvantages of using image files instead of embedded images.


@cdthomer External files? Or embedded in the clipboard (Preferences>Clipboard)?

External image files wherever possible. Less steps this way. The only time I use clipboards for images is for specific actions that require it. For instance, to set a Stream Deck button to an image I have to set a clipboard to an image first, and then set the button to the clipboard. As of now, KM doesn’t allow me to set the SD button to an image file.

There should be no appreciable difference.

Either will remove the data from the Keyboard Maestro Macros.plist file, which is generally desirable.

As @cdthomer notes, if that file gets large, then that will slow the editor down - it wont have much affect on the engine.

1 Like

I mostly store them as clipboards, good to know that is fine. Thanks!

1 Like

Thanks @peternlewis, @cdthomer, @ccstone,

This has been a very enlightening thread. My initial question has been more than answered, and the original purpose, making sure that KBM runs efficiently, has definitely been addressed.

As for macro editing workflow, it has been very quick and easy for me to capture screen clips to the system clipboard using Ctrl+Cmd+Shift+4 and then paste them into the Image Well and I would previously have recommended it.

However, the methodology of saving them as files allows me to add a form of annotation to them. I can name the clip with its date, purpose, etc. in a way that I cannot within KBM proper. (I had been considering asking for a feature to add comments to images be able to tell multiple image match options apart, but that's not necessary now; file names work for that and if makes the editor run faster, that's a total win.)

Thanks for the help, everyone.


Based on this thread from last Summer, and the performance comments by @cdthomer and @peternlewis, while I was working on cleaning up one of my most-used macros, I decided to try moving the images from the various Image Wells inside the macro to external files.

The macro continues to work, but what is lost appears to be the Display option in the Find Image action. When I have the image pasted into the Image Well, I get a green highlight on the screen that shows what part of the screen is being matched by the action. But when I have the image in an external file, I don't get the display of where the match is.

Since I am often matching images in an attempt to distinguish one part of a display from another, not know exactly what region triggered the match is not as useful to me.

Is this the intended behavior? If so, maybe the Display checkbox should go away when the image is in a file. Or is it a Known Bug?

Hey August, that seems odd. Every one of my found image actions uses an image file and I can display them without any issue.

How did you move the image from the image well to an external file? I’m curious if I’m the process the resolution or something changed enough to where KM no longer finds that image on the screen. Do(es) the action(s) work still?

Hi Chris,

At first I tried displaying the Image Well image using the Spacebar and doing a screenshot of that. I didn't care if I lost a pixel or two at the edges. When that wasn't consistently showing up with the Display highlight, I tried doing a brand new capture from the screen and saving that new capture in the File.

The Action shows that the image is found because the Until action shows the annotation of "(currently true)" when I add the image to the "until any of the following are true:" section. So it's working to find the image and make the logic decision, it just isn't giving me the green Display highlight.

It does give me the display highlight when I have either the current or the former image in the Image Well.

And your question prompt me to agree that I think it would be really cool to be able to extract an image from the Image Well and save it in a file.

Thanks for chiming in,