May I offer a suggestion for the next releases of Keyboard Maestro? It would be great if it had subfolders for macro groups. For example, a person could have one main folder called "MacBook Pro" for all of the macros that are supposed to be available only on that machine, but also have the ability to create subfolders of macros within that folder so that macros can further be limited to specific apps or app combinations on that machine.
In my case, I have 3 Mac Pros and 1 MacBook Pro at home, all doing different things. I have already divided the shared and exclusive macros for each, but now, I can't find a way to limit some macros only to certain applications on each Mac unless I create main folders for each app on each Mac. I think subfolders would help with this and provide more organization for people with many macros.
Thank you for continuing to develop such an indispensable application.
Hi @Ibnabouna Nested Folders is a very interesting idea as a way of organising Macros and which Macs they run on. But one potential problem that I can see, is it might lead to having several Macros that might be very similar to each other in different folders and sub folders. All those Macros would have to be individually edited each time you make a change which could make maintaining the Macro Library more work.
In my case (which I think is similar to yours in that I have a few different Macs all syncing the same Macro Library) I have found that I do want most of my Macros to be available on all Macs but that sometimes I want them to behave differently depending on which Mac they are running on. For this I use the Keyboard Maestro Action "Switch Case" within the Macro itself. This Action allows the Macro to do different things depending on the name of the Mac it is running on. Here is an example:
In this example I want the Macro to click on a different part of the screen depending on whether it is running on my Desktop or Laptop. But it could be expanded to include more Macs.
I like this approach because I just have one Macro and one Group for each App (not a Macro for each Mac and not multiple Groups for the same App) and I can always add or remove Mac names as and when I get more Macs. So, I only have one Macro to be maintained and edited if I need to make changes or improvements to it in the future.
In the above example one Mac is called "Desktop Mac" and the other "Laptop Mac" but you would change those names to at the actual names of each of your Macs - and it can be expanded to include as many Macs as you like as in the image below:
This means that if the Macro is accidentally run on a Mac that I don't want it to run on (i.e. not one of the named Macs) the Macro will do absolutely nothing. This is also what make this a very robust solution and one that I have used for a few years now.
Thank you for your replies. I did search before posting, but I used “sub folder” as opposed to “nested folders” in KM. The older post makes things clear that this is probably not going to happen.
Zabobon, I appreciate your workflow suggestion and will take a closer look at implementing it as a workaround later today.
In my opinion, this would depend on how organized the user is. If one is working with abstracted code (don't know the programmer term when code is sub-abstracted to component modules), you have your core code folders and your higher level folders - duplication approaches zero on the core code folders, even as their number increases, but the real-world application higher level cases becomes greater, and the need for folderizing becomes even greater. Your elegant Switch Case solutions could be handy for the latter, though I know it's always more clear to be able to enable/disable the 'copy' of the usage one needs.
For instance, I have a 12-Step foot controller that I have a dozen setups for - when I'm racing at top speed, I'm not going to dig through a Switch Case layout, I'm going to only enable that Macro Group which matrixes the incoming MIDI notes to the macro-executes wired for that case. I could be switching between three of these modes over ten minutes. Here's an example where a "12-step" folder could clean things up nicely. Within an "HID" folder. Within a folder dedicated to a year. This Switch Case works great for some things, and too picky on the 'convenience' side.
In my experience, KM is a combo of coding/development and a convenience app. There is the spun-sugar delicate micro-surgery programming aspect, and then the battle-hardened blood-and-mud real-world usage. The needs for folderizing the former are about hyper-precision and orthogonality, whereas the needs for folderizing the latter are about latenight, over-caffeinated racing to dealine bleary eyed practicality. When the Fedex man is holding a gun to your head, you have neither the time nor the inclination to build an elegant Switch/Case solution.
Every single time I program in KM, I feel like I'm stealing time from something else I should be doing - the futurized goal of time saved is often a thing of pure faith. Using clearly marked iterative/associative copies of previous macro groups can increase productivity when it's needed most. How many times has a 'slop folder' saved our lives?
Your Switch/Case idea for Group-reduction will definitely be attempted over here.
You are braver than I am. I archive all Macros for the purposes of all machines, but I only maintain one Master machine and one Languish machine. KM-Sync scares me, only because I can't rely on myself to keep all the versions the same.
I don't have many macros like this, but for those I do have I use the If Then Else action so if the specified Mac comes up the macro executes one way and if it's not the specified Mac the macro executes another way.
If it's literally a list of machines, for that kind of thing I like Switch/Case/Default instead of If/Then/Else. Switch/Case seems to vary in syntax between environments and I always have to look it up (and test it).
