It is an interesting idea. And it is very clever that you seem to have been able to do this on your own without actually changing the code of KM_GridPalettes. You simply have gone into the Resources folder of the app and found and modified the AppleScript stored there. Who would have thought it?
When I first was trying to implement KM_GridPalettes, I wondered just how Keyboard Maestro should be organized so as to respond to the requests. The most straight-forward way would be as you suggest: essentially every button of the KM_GridPalettes should be linked in a one-to-one relationship to a macro in Keyboard Maestro. So I conceived a system in my mind that every macro would have a unique name corresponding to a button. That would have been of the form: P02_05. The name would convey the palette and the button: Palette - P02 and Button - 05.
I veered away from this because I thought it would be unwieldy A huge pile of macros all in one group with this naming structure. I did not think of the structure that you came up with: each palette would be its own Group filled with macros corresponding to its buttons - At most 100 macros in one Group.
I settled on the system of having each palette correspond with a single macro and that macro determining the actions depending on the button that was clicked. Within that macro, you could have a switch that determined the action of a particular button. A natural arrangement would have each switch statement invoke a specific macro (Execute Macro) but that would not be absolutely necessary. If your intent was just to perform a couple of actions you could put them right there in the switch without bothering to actually create a corresponding macro. Even if just invoking macros (Execute Macro) you would not have to use some rigid naming structure like P02_05. You could use some more human-friendly name. And you could access macros that you had already written and assigned whatever name you did in the past and they might exist anywhere.
It is not a big deal in the sense that it is easy enough to rename or duplicate and rename an existing macro P02_05 and if you want to put in an explanatory comment, it ends up being pretty clear. As palettes get larger (more buttons), there is more that is attractive about a more "rigid" approach. Many of the palettes that I use have only about 8-20 buttons and creating and handling the switch macro is not too difficult.
There is a lot to like, however, about the scheme that you prefer, and I wonder if I would have drifted there if I had been sophisticated enough with AppleScript to implement it.
At this point, I am very curious about how things work out for you. Whether you find it agreeable and workable over time. I could probably offer a preference in the app itself or on a palette-by-palette basis to call Keyboard Maestro one way or the other. The biggest problem for me might be trying to explain the two approaches in the documentation and what the benefits of each were. I will keep rolling this idea over in my mind.
If I were you, I would probably modify the AppleScript so that the individual macros in the group did not end up with the names 00, 01, 02, 03, etc. but rather the totally unique names P02_00, P02_01, P02_02, P02_03. It just seems to me "safer" to assign them totally unique names should your needs or approaches change in the future. You have figured out how to address the macro 01 in Group P02 distinguishing it from the macro 01 in Group P03. But it seems to me that there would be no cost and possibly a future benefit for the macros in the Group P02 to be assigned P02_00, P02_01, P02_02, etc.
I very much appreciate your chiming in. If you run into some problem that requires some modification of the code of KM_GridPalettes itself, at least tell me and possibly something could be done.
)
)
