Musings: Hazel vs Keyboard Maestro

Yes, it’s another of my “musings…”

I consider Alfred, Hazel, and Keyboard Maestro to be “must installs” on every one of my Macs. In fact, Alfred is the third app I install (for those who are curious, the first two are 1Password and Dropbox, in that order. 1Password is needed for activation keys and passwords for everything else, and Dropbox is needed for data syncing for Alfred, KM, etc and so goes second); I am so used to typing ⌥-Space that I pretty much cannot use anyone else’s Mac or launch an app without it.

There is much overlap between these various utilities, and I am always debating whether to create an Alfred workflow or a KM macro. This post is not about that.

Hazel has long been my go-to app for file automation, using its rich set of tests and actions, often supplemented by my own scripts in bash, AppleScript or python. I have not, to date, used KM for automation despite its ability to trigger “monitor a folder for changes.” I prefer as much as possible to keep a given task with one app to avoid redundancy, confusion, and conflicts.

In the aftermath of David’s KM Field Guide, I’ve been playing a lot with KM, and realized that there is a use for KM’s ability to handle files in another way, however. I have been working on a macro for a specific purpose. I have a “.logs” folder where many of my homegrown scripts write log files with their operations for documentation and/or debugging. Hazel monitors that folder and renames log files each day to a file with the date appended, so there is a new log file every day, and after 10 days deletes a file so they don’t accumulate beyond bounds.

This means Hazel has to scan that folder each time it runs, which is not all that much system overhead, but it occurred to me that I really "should’ have this run more like a cron job, once daily at 12:01 AM to rotate log files, since there is really no need to check the folder any other time.

So I am putting together a KM macro to take over this function.

As a result, my “musings” have lead me to think:

  1. Hazel is the app of choice when real-time operations need to be carried out, so that continuous monitoring is desired;
  2. Hazel is the app of choice when tests and actions apply to a given folder or files in a folder;
  3. Hazel is the app of choice when its rich set of tests and actions apply to the task at hand.

BUT:

  1. KM is the app of choice when actions on files need to be run based on a specific trigger such as a particular time of day or a system event, but not on a continuous or real-time basis;
  2. KM is the app of choice when actions need to run based on a non-folder local trigger and run on files spread out amongst multiple folders, or on a selection of files in the Finder;
  3. KM is the app of choice when the actions should be run based on user triggering (eg trigger the macro via a command-key sequence, typed keyword, selection from menu or palette) rather than on a background basis;
  4. KM is the app of choice when a folder needs to be monitored but the actions required are NOT covered by Hazel or KM but are best handled via a complex scripting solution.

And so that’s how I am dividing my use of Hazel and KM, at least for now.

Thoughts?

1 Like

I’m a fan of division of labor as you outlined. It’s easier for our poor brains to keep up with.

You might want to try Karabiner-Elements. I’ve long used it to map CapsLock to F18, but recently discovered that it can be setup with tap and hold actions. So now tap CapsLock is F18, and hold is Hyper (⌃⌘⇧⌥). That means tap is Alfred, hold+N is a new note in DEVONthink, hold+C is Copy Selection to DEVONthink, etc.

Also, there is an Alfred workflow that will allow you to execute KM macros from Alfred.

2 Likes

Firstly, I left out one of the most important reasons to use KM for file management instead of Hazel. Duh.

I have a .logs folder on all of my Macs, for the log files on each Mac. With Hazel, I need to copy the rules to each Mac and maintain them on each machine, so if I make changes on one I need to update the others as well.

With the macros created in KM, I sync them across all Macs. I have an automation folder in KM that works on all Macs, as well as automation folders that are restricted to each machine for things that are machine-local.

My .logs processing rules run on all Macs via the syncing of macros via KM, which means I only need to maintain one set of rules.

I can’t believe I forgot that important reason for using KM over Hazel.

Secondly, @JohnAtl, fully agree. I have Karabiner Elements installed as well with a META key created. As in my earlier post on file remaining, META-R opens a KM palette for file and folder renaming and tagging using my various scripts. I also took David’s idea and have META-X, META-C, and META-V which open palettes with 9 clipboards to which I can respectively cut, copy, and paste to expand clipboard usage. META-M opens a palette with a variety of email templates for groups of people I email frequently. And so on.

I have not tried the tap vs hold option in Karabiner Elements, but that is intriguing. I am so used to typing ⌥-Space and it is so convenient vs the META key that I will likely stick with it for now.

2 Likes

I have been thinking of moving off Hazel entirely since enjoying David’s KM Field Guide. I also recently dove into Hazel a bit more and was stymied as I discovered that Hazel does not scale well. In my experience, Hazel fell down really early as I pushed the complexity and rule management. And I don’t like being limited like that.

I also noted that KM cron job seems like a better match for large tree(s) of files, i.e., do it once / day rather than Hazel’s notion of automatic + periodic. And the cron job provides better control over the timing, so fewer mysterious busy times for the computer.

So I’m experimenting with replacing Hazel with KM altogether, and simplifying my toolset by one.

1 Like

I believe that Hazel doesn’t look at a folder unless it gets a system message that the folder contents have changed. So it doesn’t continuously have to check the folder contents against its rules. This means its overhead is low and you don’t have to use cron to reduce overhead.

2 Likes

@tomalmy:

Thanks. A few comments:

  1. I am not sure about whether Hazel looks at folders that it has not received a system notification for. I suppose this would be a reasonable question to posit on the Hazel forums. However, I have noted that when, at one point, I had a Hazel rule applying to a folder and all sub folders, the entire tree was being scanned periodically. Now, that may well be because I often dropped files into that tree, but the Hazel logs suggested that scans were happening even when I don’t believe i had made any modifications. I also know that the file notification system in MacOS (and Linux) is not absolutely reliable - events can be missed, and so apps that rely on filesystem notifications can potentially miss things and so do need to periodically do a scan for changes. That may well no longer be the case as it’s been some time since I last read anything on this.

  2. I am not necessarily worried about the Hazel overhead of doing the scan, as I think that is likely to be pretty minimal. In the case outlined, the .logs folder only has a small number of files anyway, so even if it is being frequently scanned for changes that won’t be an issue.

More to the point, however are: a) the files in that folder change frequently but only need to be processed once / day, so a time of day trigger is more applicable; b) even more importantly, the ability to have KM sync macros across computers makes it the logical choice for this use when the same folder exists on multiple machines (but is NOT a sync’d Folder and hence needs to be processed separately on each machine).

I have no problem having Hazel monitor folders and I certainly use Hazel in preference to KM for this purpose for most such purposes. In fact, part of the reason I described in another post writing scripts that do folder renaming, tagging, moving files based on tags etc rather than embedding code into Hazel or KM is precisely to have the ability to have Hazel apply these scripts automatically to the proper folders, while allowing a KM macro to apply the same functionality on an ad-hoc basis elsewhere. Centralizing the logic in an external script callable from either utility means that I can update / revise the logic in one place and both the Hazel and KM processes update automatically.

2 Likes

The massive folder chug-chug is the problem I have with Hazel as well. It’s especially evident with my hard drive cluster since it’s loud.

However, to be fair to Hazel in my case, the drive is a NAS (Network Attached Storage), so the drive connection may not offer all the niceties (e.g., OSX notifications) that a directly attached storage would offer (but IDK).

@occam: I have been uncertain as to the actual overhead that Hazel creates when you have a lot of folders being scanned. I have thought about posting a question about that on the Hazel forums, but never gotten around to it.

I tend to think that the impact on system performance when scanning a few folders would be negligible, but if you are scanning folders that have thousands of files or having Hazel recurse down a huge folder tree, the impact would of course be much greater, more likely in filesystem overhead than CPU.

It is in part this question that has encouraged me to adopt recently an approach of using triggered macros in KM for operations that do not need to happen automatically, while having Hazel monitor folders that have a legitimate reason for automatic processing.

For example, once I properly tag and name files in my “Dispatch” folder, Hazel will move them to their proper location based on the tag-filing concept I talked about in another thread, taken from Brett Terpstra’s excellent design. Many of those files wind up in the “Inbox” of the folder tree where I store scans of bills and other “cold storage” data. From there, I want Hazel to monitor that Inbox and automatically sort those files out; if I waited to run a KM macro to do this it would probably not get done.

Overall I probably have Hazel monitoring 5-10 folders on any given machine, usually closer to 5 (I sometimes create new Hazel rules that are purpose driven, such as during tax season I have anything labelled tax that winds up in the Dispatch folder move to the folder when I am working on my tax return, but after tax season I so rarely have files or scans related to taxes that it is fine to tag and drag instead of having Hazel handle things.

I have removed rules that cause scanning down a subfolder tree. While I did not see a system impact, I tend to think that repeatedly scanning an entire folder tree is (possibly) a bad idea unless I have a good reason why that is the proper solution.

1 Like

@nlippman I agree. Your approach seems sound to me, and that’s what I aspire to for my system (based on your informative posts).

I also noticed that Hazel does not scale up… nearly at all beyond a handful of rules. And in my deep folders, I have thousands of files which I’d prefer to stage in step-by-step fashion. Hazel does not lend itself to larger systems since the UI (Preferences.app) is so limited, and the ability to edit is so limited (e.g., to one rule at a time). At that point, I decided I should find a way to do the “Hazel’ish things via (for me at the moment, given MacSparky’s excellent tutorial) Keyboard Maestro (KM), kick in a few more sophisticated workflows into the KM mix (KM+), and then consolidate on KM+.

Of course, that’s challenging and I haven’t succeeded yet. To give credit where credit is due, Hazel does some very important and pragmatic tasks very easily and (within its practice limits) very well. So I don’t regret using Hazel, nor do I recommend getting off Hazel if it works for you! But (for my own stuff) I do look forward to finding a more scalable, equally (or more) powerful solution… probably via KM + some scripts.