I’m hardly an expert, but this philosophy strikes me as very similar to the structure of Unix itself that I’ve heard over and over… a lot of very simple things (in this case, small programs) that can be used by themselves, or chained together to make unimaginably complicated workflows. It’s a philosophy that seems to have worked well for Unix, and also seems to work well for Keyboard Maestro.
In fact, when I’m exposing someone new to KM, I always start by helping them construct something very, very simple at first. For example, adding a save keystroke (Command S) to the F1 key, or something similar. They are often amazed at how quick and easily that’s done. Then I just leave them with that for a week or two. Inevitably, they will want more, and we will slowly build complexity from there.
But it’s all facilitated by the simple concepts inside of KM itself. I didn’t realize that this was a deliberate philosophy by Peter, but now it makes sense.
Absolutely. The first piece of advice I give to any new user is to start simple. Pretty much anyone can use Keyboard Maestro with hot keys and single action macros and get a lot of value out of it without doing any more.
It's unbelievable how much you've managed to accomplish with KM all on your own. Truly.
I just pray to whatever gods will listen that you have some sort of plan in place to pass on the product/codebase when you finally decide to retire—or, more likely from the sounds of it, when you finally die at the ripe old age of 110 in the middle of coding version 50 haha
But in all seriousness, I can't even imagine using a Mac without Keyboard Maestro anymore, so I really do hope it survives for at least as long as I do...
Yes, indeed Keyboard Maestro should have been the killer application for Mac. It is gratifying to see mouth open when KM works its magic time and time again.
It is one of those applications that one must experience before meeting his maker.
This has been a problem for me too. For a long time I only used my special macro killswitch hotkey for cancel all macros if something went amiss. A few times a hidden running macro got too out of hand and jammed my system up to the point that I've had to force quit KM or even restart my computer, but in general the hotkey for cancelling all works really well.
However, I've recently come up with something new I really like. I'm not sure if this is how other people usually operate but I generally only use one macro at a time on a loop. For me, with this usage, I've begun to start each macro with 'cancel all other macros'. This won't keep a hidden macro from running if I'm not currently proactively using a macro, but it does ensure that I never accidentally have a hidden macro running while I'm using one.
A better solution is to switch to using a Loud variant in the status menu icon so you can more clearly see if any macro is running. You can also see and cancel the running macros in the Cancel submenu in the status menu, or use the Macro Debugger.
Thanks! I just downloaded the icon variants so I'll know when I'm not actively running a macro. However I still think the 'cancel all other macros' on each macro is the best solution for while I'm actively running a macro, which is often. I wouldn't be able to tell by the Loud animation since it'd be running anyway, and it's easier than manually checking the status menu cancel area or debugger. The only caveat would be if having the 'cancel all other macros' action added to each loop would slow down the macro, which I've wondered about.
It wont. But that's not the only caveat. The big issue is if you have any background macros, they will be canceled. For example, I have a macro that runs every minute which tracks my usage and how long I've been working to remind me to take a brake, and another periodic macro that updates my desktop with a satellite image of the world. If you triggered such a macro while a background macro like that was running, it would be canceled midway through, perhaps leaving it in a weird state.
That's very true. In fact, that's basically the reason why I stopped using background macros altogether. I had too many instances of starting a random hidden macro that caused a mess, so I began using 'cancel all macros' very often when making or using macros to make sure I was clear in that regard... which of course cancelled my background macros. So I just decided to do away with background macros, which is why I can use the 'cancel all other macros' so readily in my macros now. I miss my background macros but it is easier this way.
[ETA - It's not true that I've actually completely done away with background macros or what they were doing. Instead, I've reworked my active front macros to include background actions I want to run. I make separate macros for specific things that used to be 'background' separate macros, and then instead of looping them, I add them to my other macros as an 'execute a macro' on each loop, or if the loop is too short then every so many loops or use an if/then. Then, if I have no other macros running and want the background-type macro running I can run a looped version. It's more tedious and less graceful than a simple background macro running and so with time I've used them less and less but I do still use some in this way at the moment.]
I may rethink that after reading your comments, but there's still the possibility of a hidden macro starting while I'm using another macro, and in that instance I would not be able to manually look at the drop down status menu while my main macro is actively working. Though I see now that there is the option of leaving the debugger open in a dedicated section of the screen, which could work if I'm there watching the macro.
I do sometimes leave a macro running while I'm away from the screen which could cause a problem if a hidden macro somehow started when I'm not there, which has somehow happened to me before and created a big mess (I don't remember the details, but I suspect I didn't have the macro loop perfectly set up and some rare instance if/then popping up triggered either hidden macros or multiple instances of the same macro to run concurrently which is just as bad or worse). However, I can see a way to work with the debugger with this, perhaps using a found image to detect if something more than what is supposed to be running starts up and pops up on the debugger. Using found images are always my least favourite option but if it works then it's possible. I also took a quick look at the debugger macro actions list which I've never used any of, and wonder if perhaps I could add a 'debugger new macros paused' to each loop so that if something somehow starts it's automatically paused, if that action is what I'm imagining (I'm not very familiar with the debugger).
Macros that start un-commanded (eg periodic or time based macros) should be created so as not to have any impact on the UI (so things like running shell scripts for example, but not things like launching applications).
Alternatively, macros that want to start un-commanded should use some way to notify the user that they are about to run - wait until the IDLE function indicates that the Mac is at least somewhat idle for example, then notify with something like a Notification or Display Text Large, then allow time to cancel the macro and then proceed.
But at the end of the day, whatever works for you is fine - if you want to cancel all macros every time you run a macro, that's fine as long as you're aware of the consequences.
jk
