Dan, you usually do great stuff. But if this is so important, then I’d suggest that you first explain what it does and why we should care. Maybe even a short video would be in order.
As you know, most active developers are very busy. If you ask me to do something as a favor, then of course I’d do it. But for a general call to all developers, I think you need to share more with us up front.
I could just explain the issue. But when I tried, the explanation was so long that even I wouldn’t read it if I didn’t need to. I was hoping this would explain things in a way that more people would try.
But I understand completely what you’re saying. As I said, I was hoping this would have the opposite effect, but I guess it’s a fail, LOL.
The issue is fairly simple. Both “Example Macros v1” and “Example Macros v2” has two macros with the same two UUIDs (lets call them UUID1 and UUID2). In both cases Main Macro refers to the second macro as UUID2.
If you import either by themselves, everything is fine. As long as you delete the existing macros first, everything is fine to import either one again.
But if you import one set and then the second set, both the second set macros would have duplicate UUIDs, so both get new ones (say NUUID1 and NUUID2). Unfortunately, Keyboard Maestro is not clever enough to remap references to them, so the NUUID1 macro still executes the UUID2 macro.
Essentially this is a bug in Keyboard Maestro’s handling of importing and duplicate UUIDs.
As for testing a new version, you could always export the old macros, then delete them, then import the new ones. If you don’t like the new ones, you delete them and re-import the old ones.
The problem with MIM is that there’s no guarantee that the user has it installed. I suppose we could wrap the macros inside some kind of package, and require the user to install MIM (which would know how to crack the package and get at the macros inside).
Another option is to wrap the macros inside an Installer applet. I actually have a working version of this. The Installer applet is basically a bundle with the new macros inside it, along with a KM script that handles the import process. When you double-click the Installer applet, the small JXA or AS script inside it tells KM to “do script” passing it the installer script (a set of KM Actions that does all the work), along with the path to the macro files inside the bundle.
Let me know if you want to see a demo of this. The problem with the Installer applet is that it’s not signed, so depending on the user’s security settings, they may not be able to run it.
That’s not how I do anything else, and, IMO, will be way too much trouble for end users.
I don’t know, but I’m guessing that macros created by most users don’t use sub-macros. So It’s not an issue.
But you, I, and others, have seen the age-old utility of subroutines (sub-macros), and we immediately are drawn to using them. While the KM “Execute Macro” provides for this, it is not true subroutine functionality. As @peternlewis as stated, Keyboard Maestro is a “visual programming language”. We create macros by stacking Actions, most often done (just guessing here) by drag/drop.
I suggest we should consider the following:
What is the ideal behavior we want?
What are @peternlewis’s thoughts about supporting any of this in the future?
Meanwhile, back at the ranch, I really have not been impacted by this so far.
Mostly, I suspect, because there haven’t been other KM developers creating and publishing macros with sub-macros. I have quite a few myself, but only one or two macros that I have published. And yours are the only macros that I have downloaded and actually use on a frequent basis, which also have sub-macros.
So, this is an opportune time to make some big decisions, but there is no looming crisis.
This issue is actually even easier to produce. Simply create two macros, one that executes the other, select both of them and choose Edit➤Duplicate. The duplicated macro will execute the original sub-macro.
Basically, when you insert (in any way, Paste, Duplicate, Import, etc) a set of macros, references to other macros within the set will be retained. If any of the inserted macros or macro groups require new UIDs, any macros also inserted will have their reference updated to the new UID as well.