[Feature Request] Go to Macro in Execute a Macro

Questions & Suggestions
#1

I would like a menu item (and keystroke shortcut) that with an Execute a Macro selected would go to that macro. I have “submacros” in various folders, plus I don’t necessarily know whether the macro I have selected is in the group of the current macro or one of those other folders. Yes, I can search for it – select all macros, type in enough of the macro name to narrow down the search, then click the one I want (and hoping by the time I’ve done all that that I remember the exact name in case there are several with similar names).

Is this a ridiculous idea? have started to post this several times and decided not to. But by now I have wanted this enough times that I have decided to go ahead and request.

[Feature Request] Smarter Palettes
#2

It’s so odd you would post this right now, when I’ve been wrestling with this concept today myself.

Here’s one thing that’s helped a lot (and it comes from other people - I’m just now reaping the benefits).

Rename your sub-macros to have the Group name in them like this: “[Group Name] My Macro Name”. Then, as soon as you see the name, you’ll know where to find it.

The second thing this allows, is you can create a temporary group, and drag the sub macros you’re working with to the group (but don’t change the name of the macros). When you’re done with them, you know right where to drag them back.

As for going right to the macro, I don’t believe there’s anything in place for it right now, but I’ll bet it could be worked out, if we thought about it long enough.

1 Like
#3

Its on the todo list.

1 Like
#4

Hey Guys,

Not quite what you wanted, but it works.

tell application "Keyboard Maestro"
  activate
  editMacro "Generic-Test 01"
end tell

You can use the macro name or its UUID.

-Chris

#5

Hey Chris, looks good – you’re almost there.

So now we need a way to read the name of the macro to be executed in the “Execute Macro” action. If that action is selected, can we get the name somehow? From the action .plist?

#6

If you copy the action, the copy will include the XML of the action. It will be in a private flavour (com.stairways.keyboardmaestro.actionarray), so I’m not sure off hand how you can access it (JXA or AppleScript can probably read custom flavors). And then finding the UUID of the target macro would not be difficult from there presuming you can parse the XML.

#7

That helps with searching and with visually recognized the macro name in the list of macros, but it does not tell me the group the macro is in. Searching is slightly facilitated, especially in that it will show all submacros that a group uses, but I could just as well type in part of the name of the macro I am looking for in a search.

#8

Sorry I wasn't more clear. Here's an example:

#9

Ah. You meant to put all the macros beginning with (???) in a separate macro group named (???). That’s not bad, but it clutters up my list of groups with many groups with only one or two submacros.

#10

Man, I’m not getting this across, am I? LOL.

No, I mean that whatever macro group you put a sub-macro in, that’s the name you put between the brackets. So if you have macros in a group called “AA”, then you name the macros (or at least the sub-macros) like this: “[AA] Some Sub-Macro”.

The point is, you can look at the name of the sub-macro and know immediately what group it’s in, because the name of the group is actually part of the macro’s name.

By the way, I wasn’t a fan of this until I started using it. Now I love it.

#11

Dan, maybe I'm missing something, but I don't see the benefit.

If I have a macro open, the Group is highlighted in the Groups panel.
If I have All Macros selected, the Group shows at the top of the macro:

OTOH, adding the Group Name to the Macro Name has these cons:

  1. More typing
  2. Makes it harder to view the Macro name in the Macros list panel. I have to make it wider to view the macro name
  3. If I change the Group name, I have to change the Macro Name

If it works for you, or anyone, that's great.
But it's not for me.

#12

I guess I misunderstood: you don’t put the specially named macros in their own group, you keep them in the group that contains the macros that use them? My problem is finding a submacro that’s in a different group than the one containing the macros that use it. Sometimes the reason they are in a different group is that I don’t want them on the main group’s palette. (Peter has warned against using disabled macros as submacros, even though it appears to work.)

#13

In addition to which, I might use the same submacro from several different groups. (That complicates packaging if I want to share the group with others, but makes things easier for me. I have started to have a couple of Utility groups that contain just submacros. And I should put the name of the groups that use the submacro in its comment. That would improve things in that there are only a small number of groups where I would find the macro. (This doesn’t work if I use a top-level macro also as a submacro.)

I just an interesting case where two macro groups I have been trying to distribute for a couple of weeks share one submacro. I ended up just doing a copy and paste, and every time I edited the macro I had to repeat the copy and paste. In the end this isn’t going to work for me because I don’t want the submacro appearing in the group’s palette, but sometimes it might be a reasonable way to go.

#14

I’m keeping it simple: I put ALL of my sub-macros in a Group named “Sub-Macros”.

Makes it easy to find and maintain.

#15

That’s not the point - it’s when there’s an Execute Macro, it makes it easier to find the referenced macro. That doesn’t show at the top, does it?

Of course if they’re all in one group, that solves that issue. But even if I were to put all sub-macros in one group, I’d prefix the ones that are app-specific so I could find, say, all Mail-related sub-macros.

#16

Yep, I’ve been doing that for a while with all of my macros, not just sub-macros.
I use a very brief code, in brackets, like “[OL]” for Outlook focused macros.

#17

So then, you mostly use groups only for Palettes and application-available macros?

#18

Yep. See:

#19

You know, I saw that, but I didn’t put it all together. Sometimes I miss the forest for the trees.

#20

That’s what I have been doing, though I think I split it into two groups: UI manipulations and macros that do more programming-like tasks (macros, AppleScripts, soon I hope ASOjbc, etc.). Not a clear distinction, but good enough. Until I have tens of macros in one of the groups, then I’ll split.