Feature Request: Nested Folders For Macro Groups (Macro Group Management)

macrogroupscrazy

Hi Peter,

My KM scrolling finger hasn't minded the enormous list of Macro Groups until today - it's pretty crazy now. Per the image, the lack of a folder structure has meant, for me, careful nomenclature of Macro Groups (which, as associative to palettes, can be ugly or non-optimal) so I can at least isolate by function (core, HID, keystroke, palette), focus app, task-use group. "Flavours" and alts of Macro Groups sometimes want folderizing. But it still makes for a VERY LONG LIST with hundreds of Macro Groups. :slight_smile:

Much of my KM use/ideas come out of the Pro Tools (#protools) universe. You may have heard about the big wing-flap recently that PT finally got folders and folder-tracks after 23 years. It's a sad, sad, bloated implementation causing ripple effects on the functionality of the rest of the app. I empathize that major architecture shifts can be difficult/involved.

I don't think it would be too daunting for a beginner to be faced with the difference between Macro Groups and 'MGGs' (Macro Group Groups?) if they were simply called 'Folders' or 'Macro Group Folders'?

My organization would be like:

renton_hier

Immediately, people would want programmatic, hierarchical control of these Folders, and also to Import/Export within this scheme. For me, these would be nice-haves of course, but just a GUI folderizing scheme in the left panel of the Editor Window. Would be useful.

Often it's the case that until you try building an organizing schema and then forcing yourself to use it, you suddenly realize how utterly essential it is to your workflow. Revelations have been had recently with Pro Tools, and I suspect it could be time for this in KM as well.

Am I missing anything? Is there an organizing scheme beyond naming, Macro Groups and Smart Macro Groups that I could be using for this?

Thanks for your time.

Folders for Macro Groups is on the wishlist, but it is probably not something I am going to implement. It adds a lot of complexity in terms of both UI and support code, and benefits only a tiny fraction of Keyboard Maestro users, which is not a good combination.

Thanks Peter. Yeah, i figured this might be the case.

And it might be a little lazy on my side, as i could export and library
the macro groups/macros i no longer use on a regular basis - keep it
clean. a bit greedy to want it all out and open so i can grab the ideas
from here and there.

it does kind of infer an aspect of limitation, but you're right - i'm
probably in the 8% who go that hard with it.

thanks for getting back to me
k

Tags might be more useful anyway.

If you aren't using them, you can disable them and then turn off View ➤ Show Disabled Macro Groups, which hides all the disabled macro groups.

I agree. I have about 162 KM Macro Groups now, and would have many more if KM supported sub-Groups.

May I ask how do you know that?

We are all used to having folders and sub-folders in the Finder.
So it is a very natural organizational tool.

Evernote took this same design attitude from the beginning.
Today, there are many, many EN users who continue to complain/request sub-notebooks (sub-folders).

I don't understand this. We have had tree UI structures for decades now, and surely there is a lot of support for implementing this.

I know people use tags very effectively. But for my own workflows, hierarchies are tags with meta/semantics in-built. A folder is a defined, checkable entity whereas tags are a bit iffy for my uses. I recently had a roll through a Shopify job where the navigation is the the tags, but this is only effective because there's a structure displaying the tagged items (items outside the nav scheme are space dust).

But perhaps what we're asking for is a tagging system for Macro Groups, and then a Shopify-style nav system which will round up tagged items in a sensible structure. This could be a GUI-level thing without having to rebuild the whole app from scratch.

Unfortunately, seeing a Macro Group disabled and greyed out is as important as confirming the ones that are running; ie. knowing which of the set is active at a glance is key. Scanning the list is important. I'd just like disclosure triangles to be able to put active/disabled related MGs into their own home, to be used in a daily, minute-to-minute way.

The simplest example of splitting out forum lessons from one's own work sells the idea. Using a prefix naming system is fine until you're into the hundreds. :slight_smile:

I'm very grateful that KM doesn't collect analytics data. Native Instruments seems to give consent boxes but then goes ahead and ships off the collected data anyhow. I'm sure @peternlewis knows how his demographic breaks down into single-fix-users, casual users and lifers.

I know the UI would be a pain, especially because directories take up a lot of horizontal space when the Macro Groups panel is already tight (but this is partially because MG names have to be so long in absence of nav).

The extended ideas of being able to programmatically active/inactive a folder of MGs, or access macros through their nav... and that level of work... this is overkill. I would think that a simple database lookup in the prefs of MG_idnumber against a nested array of what lives where. Dragging around folder to folder would be nice, but you could use the "Move ->" plan from Things 3 or similar. Something akin to the bookmarks org in Firefox or WordPress level nav. It's making me nauseous just to think about it, so I can see why this would be daunting and horrible.

My only point in this reply is that GUI/pretty is the only thought, nothing adding to the functionality or meta of KM. We specifically want the MGs to perform correctly as we shuffle them around for the human brain into context.

Tags is actually the opposite gesture - add geographical meaning within the app where hundreds of Macros each inside hundreds of MGs are hard to track after a certain threshold (which will be different for everybody).

mgs

The reason I had to double-check myself that a folder system didn't already exist is because there is ALREADY a MG nav implied with the programmatic Macro folders at the top of the Groups panel.

I would also be very happy with the more experiential Apache type web-browser type scheme, where you "drill in" and have a _parent_folder link at the top of wherever you are.

parent

Imagine clicking on the Enable Macros folder and then you're "in" it, faced with more files and folders. This is also compact, horizontally.

Native Instruments Kontakt has a similar system, compact and space-saving, but it is less enjoyable and fussy.

Increased organization could be something to look at for KM v10.

I don't know if anyone cares or not, but a bunch of the macros I've uploaded to this forum, that a lot of people use, would break if nested folders were implemented. I don't have the time or energy to fix them, so for me personally, I'm thankful @peternlewis isn't going to implement this. :smile:

1 Like

specifically so they wouldn't break, the idea was to continue to reference macros/macro groups by name or id or however he s currently doing it. (if you move these things aroubd they still get found). nav tree as I suggested would be UI convenience only with no changes to ref ids internally.

3 Likes

Ah, I get it.

But a refid is an inscrutable thing.

the scrutiny is PNL's alone. we don't want to scrutinize any parameters
or fields, or add any feature-complexity to KM, simply to have a means
to UI visual organization of hundreds of Macro Groups, and also create
an analog in import/export.

each macro group quite obviously already carries some unique id number
since scripts can reference them. we just need an array in the prefs of
where these can live in a nested folder tree. it shouldn't break
anything.