As above. I'd like for an installer app I'm working on to be able to install Macros into a Macro folder for an app Without the user needing to install them manually. Is this possible?
Without the user needing to install them manually.
I wonder if that sounds like a good idea ?
Could easily be translated to:
without the user knowing that they've been installed ...
I hadn’t thought of it that way - but I suppose someone should. I’m thinking about making that a part of an installer app for a suite that also uses KM macros as an option. It’s the kind of thing I’d take with me and install on another system I would use, or that someone else could use also. Of course, the user would be aware of it. And it’s not as if a user installing them is difficult - I’m just looking to streamline.
Since you raise this point - what about this approach? Does this seem too invasive?
The installer installs Macros in a folder in the user's ~/Documents.
I could add an AppleScript to be executed by the installer that would select the macros in the finder and double click, which will install them in a new folder in KM, deactivated; and the installer should prompt with these instructions:
"To complete the Keyboard Maestro Macro installation:
Open the Keyboard Maestro Editor from its menu bar icon.
In the Groups column on the left, click on the folder "For your [appropriate app] Macro Folder".
Select the contents and copy (command-c).
Click on your [appropriate app] macro folder in Groups. Paste (command-v).
Select the new macros, control-click on them and choose "Enable" from the options.
Close the Keyboard Maestro Editor window.
Done!"
I might lose some of my privileges on this website (or at least have my posts removed) if I helped people "streamline" by removing important security features, such as by undoing the built-in disabling of any new macros.
You can do whatever you want. You can even remove security features, but it's fairly unlikely that any of the wizards here will help you with that.
I don’t want to disable anything. That’s the entire point of the double-click install - they are disabled when imported.
Okay, that's better, although it originally sounded like you wanted the security part of the process disabled when you wrote "without the user needing to install them manually." Enabling them is part of the manual process. Hence the confusion on my part.
Upon further review of your prompts, it seems that the macros you want the user to install are not already in their final destination folder. Why is that? That looks like a big mistake. Why can't you place the macros in the correct folder from the beginning? This would save the user from having to read your prompts and move the macros manually. In fact, your instructions are having the user COPY rather than move the macros. This is a second mistake, as copies of a macro with the same trigger will result in minor to very serious problems, depending on the trigger attached to the macro.
What is wrong with the current mechanism? All the user has to do is double click on the file, and the macro shows up on the screen instantly, awaiting the user to press "Enable." There's nothing really to streamline there. It's about as simple as you can get.
Being concerned about security is a valid and important thing to me. But I don’t see anything from my point of view that indicates my intent was or is to bypass security - maybe there’s a subtle difference between what is possible to someone with a greater awareness of these possibilities than mine and what my intent might be. I’m fairly new on this forum - do people come on here asking how to do nefarious things in public?
I absolutely appreciate your awareness of the issues, because now I know something I didn’t, and I wasn’t thinking about any of this at all before now. But what I do know is that double clicking on a macro or group of macros opens them up disabled. And the group is disabled. So that seems secure to me.
The reasons I want to do it this way:
I want to have a single installer that does lot of things. Macros are not the only thing getting installed. But they are an option that has to be specifically chosen, and the user who does so knows they want them installed. Could I just put them in a folder and say “now you install them”? I could. But I want to know what’s possible as far as making this more streamlined. To me that means putting them in KM, and only requiring the user to put them in the desired folder or folders - since these macros would work with a number of related apps and revisions of apps. That’s a slightly unusual scenario, but there it is. The group that these will end up in depends upon the version and flavor of the app, so I can’t anticipate that.
The typical user for what I am doing carries with them a probability that they would make changes to things that get installed. I offer a fallback position in that these would be disabled and in a disabled group that would not interfere with any operations, as far as I can see.
Another possibility is that I redo these macros in AppleScript and don’t involve Keyboard Maestro at all - but the thing is, I would like more people to use this platform, and I want them to have more reasons to do so.
How is adding extra dialog boxes more streamlined? To me, that's less streamlined. It's already as streamlined as it can be: there are no dialog boxes you need to read and comply with.
You can do anything you want, as I said. I asked you a couple of questions about your way, and you didn't answer them.
Now I have a third question for you: how do you want your solution triggered? I don't think it can be triggered by the user double clicking on a macro file. So how do you want it triggered?
Thanks for your help and input.
If i understand your logic here, why not just have the original macro file be the "fallback" and have the macros correctly foldered in their initial install state? If your imagined user modifies the macro and breaks something, there is always the original kmm file in their documents folder, or whever it was downloaded.
Also
Not via python as far as i know, but Applescript can import macro groups and enable them. I do something similar to update / install a macro set for a set of internal tools I use at work.
1 Like
The apps and versions of apps that these macros address have varying names, so I can't anticipate what they would be, and thus I can't export them as being in the correct folder already. And you are right that the user would have it from the basic install. To be honest I liked the idea that it would already be there in KM, albeit disabled, so they could just copy/paste it. I'd even considered removing it from the documents folder once it was opened by KM just to declutter. If a user needed the unedited original they wouldn't have to go look for it - it would be right there.
Interesting about AppleScript. I do kind of prefer that the user enable them, because that's a reminder that they can turn these on or off, and they have control over what runs on their system. If it were just for me I would do it with AppleScript, but for other users/customers that might seem a little invasive. It's kind of like the uncanny valley - if something does a lot of kind of invisible things with your system, in the first place more can go wrong; and in the second place it can feel uncomfortable.
I wish there was a way to manage macros in different files (not necessarily with a python app. Basically the user will be able to specify one or more files from which macros are loaded.
Currently, when you share macros between computers, a plist file is created. It is not difficult to write a script that will generate this file. In this file, each macro has a set of attributes. For example, I could envision a script that takes the current macro files and adds the macros found in another file.
this will facilitate organizational management of macros. I have talked to coworkers who would be interested of using KM if there an easy way to create a set of common macros for our job that we can all share.
Having such script will help a little, but the ideal solution would be to be able to designate one or more files to separate macros (team's shared, friend's shared, family, etc).
The other issue is that the current plist format does not facilitate version control. Unless it is converted to a readable format (which is not hard, run plutil -p -f , but it requires an extra step if one is to version control ones macros).
I suspect that @Peter would prefer not to have to worry having to provide error messages if this file is to be written by the user (currently, because it is a binary format KM does not expect any errors in it).
And yes, it could be done in python with the help of command line tools to convert to plist files.
I wonder how many people would want this feature. If there are big corporations that purchase many licenses, maybe that would persuade @peternlewis (not @Peter) to implement something like that. I don't see any problem with your idea, but The Architect has a long to-do list and if this feature isn't in great demand, it's not likely to get implemented soon.
The good news is that I think KM is starting to get close to a new major release, (it's typically updated every 2 years) and you might get lucky.
P.S. Nothing stops you from writing a program that does this. You might even be able to write it using KM actions.
I suspect that hacking the plist is the wrong approach -- a scripted import of macros might be better. And your "work" common macros could be segregated from "personal" by using an agreed naming structure for Groups.
Working at the macro/XML level would make version control easier too.
1 Like
If you mean you are going to merge macros in to the Keyboard Maestro Macros.plist, then either please do not do this, or never, ever ask for support for any issues ever afterwards, because even I would never try to do that.
The only way to modify the Keyboard Maestro Macros.plist (for anything other than the most trivial of hacking while both Keyboard Maestro Engine and Keyboard Maestro are not running) is via the Keyboard Maestro editor.
1 Like
Others have chimed in here, but just wanted to add a note that I've done exactly this with a group of macros that I share with my co-workers. Here's a few high level ideas that detail how I've implemented it.
- Dedicated macro groups with a specific prefix are part of the main macro set to make it easy to distinguish "personal" from "work" macros.
- The macro set (containing multiple groups) is in a dedicated folder on a shared cloud storage volume with specific version naming. XX_Macros-v001.kmmacros
- An "Installer" macro, periodically checks for new macro versions in that folder, and when it finds it, deletes the existing macro groups via applescript, imports the new macro file, activates the new macro groups via applescript, and increments the installed version in a global variable.
- I also support downgrading to the previous version in this installer macro, in case i break something, as well as remote triggers, in case I want to forcibly upgrade or downgrade everyone.
- I had to also make an "installer installer" macro that does essentially the same thing as the installer macro, but allows me to update the main installer macro in case i want to add functionality there.
It took some trial and error, but we've got a really nicely functioning version controlled system where I share several hundred macros over about a dozen macro groups across 25 or so computers with my co-workers, i'm on v396 as of today! I install various dependencies via brew, or python virtual environments with the installer macro as well which has made it really easy to roll out new ideas quickly.
I can't post my Installer macro since it contains some proprietary information, but I'd be happy to break out pieces of it and remove sensitive information if anyone would find it helpful.
4 Likes