Understanding Use of Trigger by Script

This means, it belongs to the triggers thar are affected by the check box. That is: if the check box is selected, the trigger works. If not, the trigger doesn’t work.

Yes. And I understand all of them, except the first one. I understand every kind of script in that list. But the first one doesn't explain what kind of script. It's the only one that lacks a description. That's why I don't understand it. What is it?

The first one (“Or by script.”) can not be opened. It is just the heading of this popup menu. The other entries can be opened and they give you a code snippet (in the respective language) that allows you to run this specific macro from within a script (AppleScript, JavaScript, Python, whatever).

Oh! It does nothing! It's just a "label"! That explains it! It's a functionless label! Thanks!

Yep, I think “label” is the correct wording, thanks.

Thanks. I truly did not know it was a functionless label. I actually thought it was an option that did something (enabled/disabled something) that I didn't understand. But now it's obvious. Thanks.

Now, go on and try one of the script triggers. It’s easy:

For example open the Apple Script item, copy the snippet into a new AppleScript (in Script Editor or Script Debugger), then run the script.

The AppleScript should now have run your macro. (The one from where you copied the snippet.)

I've used some of those before. I understand them. The only thing I didn't understand was the label thing. Now you have cleared up one of the most enduring mysteries of KM that I never understood, thanks.

1 Like

Yes, the punctuation is a bit misleading. Instead of “Or by script.” I would have written “Or by script:”. And then for the individual languages “By AppleScript…”, “By JavaScript…”, etc.


Note that English is a foreign language to me. So, it is possible that my perception of the punctuation is affected by the punctuation rules/habits in my language.

Understood. No worry.

Upon reflection, I don't think I like how KM manages this issue. Ie, a macro is either disabled by all scripts or by none. All at the same time. That seems so inflexible. And to make matters worse, you can't disable it at all if it's called by an Execute Macro action.

I would prefer that the phrase "> Or by script" be replaced by "Choose activation methods >" and then a list of checkboxes for each of the eight different activation methods. That makes them all independent, INCLUDING a ninth checkbox for "by Execute Macro action". But then you still need a text box for each one giving me the code required for each type of script. There could be a little triangle/arrow beside each one that lets you expand it to get the text.

It is disabled for all script triggers, if the check box isn’t selected. (If not, then it is clearly a bug.)

That’s why I perceive it as much more clearer now. With KM8 you always had to guess:

  • Can a disabled macro be run via script? [correct answer, IIRC: no]
  • Can a disabled macro be run via an Execute Macro action? [correct answer: yes]

Now (with KM9) it is clear that only the triggers in the macro header (e.g. Hotkey, script triggers, …) are affected by the “disable” check box. Not an execution via Execute Macro.

The fact that an execution via Execute Macro is not disabled can be very useful, for example when you have a macro group with a dedicated palette, and you want only some macros appear in the palette. (The enabled trigger/launcher macros, but not the disabled “helper” macros; the helper macros might be executed from within one of the trigger macros.)

That would be an option – as long as this deactivation is separated from the “global” deactivation. (Though I think it isn’t needed.)

This wouldn’t work because a hotkey trigger for example is also an “activation method”, no?

I don’t understand this. You get the code snippet by selecting the script language from the menu:


That’s why I proposed an ellipsis (instead of “:”) for the script-language menu items. From the Apple Style Guide:

ellipsis A set of three dots indicating a continuation […]

And from the Human Interface Guidelines:

Use an ellipsis whenever choosing a menu item requires additional input from the user. The ellipsis character (…) means a dialog or separate window will open and prompt the user for additional information or to make a choice.

(Well, in a strict sense, no additional user input is required here – except pressing ⌘C, but the user can make the choice to copy or not to copy the snippet. And it’s a continuation in any case.)

But these are clearly first world problems :wink:

Since I'm not at all clear if you understand my viewpoint, I've created a couple of fake images to illustrate my idea:

Then when you click on the PLUS sign you see this:

Plus a ninth box for "Execute Macro Action" which I forgot to add above.

In my mind this would be more in keeping with KM's theme of absolute power and flexibility.

You said that this wouldn't work because a HotKey trigger is also an activation method. You don't seem to understand that I'm not changing the Trigger section at all. I'm just creating a new section below it. hopefully my new images illustrate exactly what I'm thinking.

Also, instead of a colon at the end of each script type, there would be a little triangle to allow you to get the sample code that's visible in a different way now.

I think I got you perfectly fine.

I just said, the “INCLUDING a ninth checkbox for "by Execute Macro action”” would be a more or less reasonable option. But not introducing a check box for each script language (sorry for not being explicit). Why would you want that?

I understood that you spoke about renaming the script-triggers section. That’s why I said this will not work (semantically), because a hotkey trigger is also an “activation method”.

Oops, you got me on an inconsistency there. I'm embarrassed. Well, KM's not likely to ever change in this regard so I don't really need to fix my inconsistency.

Why would you want the possibility to enable/disable each script-language trigger individually?

There's a principle in security called the "least privilege principle" that you grant someone only the permission that are needed. I always go by this philosophy. Why should I be forced to allow all Python scripts on my computer to be able to access a macro just because I want my shell commands to be able to access that macro? That doesn't make any sense to me. It's for my own security that I want to be able to open one door at a time. Just one door at a time. It's safer.

I understand what you mean but any script can only run your macro if it addresses that macro by the UUID or by its name. So, the chances that any maliciously introduced 3rd-party script will trigger one of your macros are pretty negligible. IMHO. But, in a very strict sense, your argument is valid.

Hey guys, great discussion about trigger by script, but is really a different subject from where you posted. So I have moved all of your discussion to a new Topic where it can be easier to find and reference.