Trigger on a Active Window with a Specific Tltle..? Possible?

This is a basic question, and I feel like I know the answer, but I have to ask.

Is there a way to Trigger execution based on a Window Title ?

I just noticed on MacOs windows don't seem to have a title, so maybe this isn't possible.

I want to Trigger when a "specific" web page loads in Chrome. I was looking for a Title window, which worked on Windows, but can't dial in a solution to do this w/ Keyboard Maestro..

Well, there is a trigger for every time the focused window changes. And you could use a group to limit it to when Chrome is active.

I use this myself for a crazy-elaborate window management system. There's no noticible performance hit.

IME with macOS Mojave, most Mac windows do have a title. Those that don't are usually a popup dialog or speciality window.

You can easily get the window title using KM WindowName Token.

You can't trigger on a specific window title, but you can trigger on:
Focused Window trigger with these choices:

See the above KM Wiki article for details.

So you can trigger on when the focused window title changes, and then test for a specific title using a If Then Else action.

Is there any way to stop the cluttering of the engine log with this kind of setup?

I've been using something like it for a year or so but it means that 90% of the log entries are the switcher macro for determining the current window. Any thoughts?

I too find the KM log file to be too verbose, 99% of the time. I think this is a problem when you are looking for log entries not related to these verbose entries. @peternlewis, I know you hate clutter, so how can you stand the clutter of the KM Log? :wink:

IAC, there is nothing we as users can do about it, except to ignore it.
Many Mac developers offer an option for the level of their app's logging. Something like "Minimal, Normal, Verbose (debugging)". I don't care what you call it, but I would prefer minimal logging except when there is an error or unexpected behavior.

Well, maybe there is one thing we can do: write our own log processing tool so we don't have to look at the raw log. I have done this. See

MACRO: Display Last KM Macro Error


Thank you MichaelTX, I don't know how I missed that.

Hope to return the favor,

Patrick (austin, tx)

Because the log is just that, a log. People generally should not be looking in it unless there is a specific problem to solve. Noting every single macro that is triggered is pretty much the most essential part of that, since people often end up with macros either triggering unexpectedly, or doing unexpected things, and finding this is probably the primary purpose of the log (that and reporting exceptional cases).

There are a couple of log entries that shouldn't be there (most notably the endless complains about Apple’s crappy NSRunningApplication API, but that is me venting).

If you want to log specific things, you can use the Append Text to a File action to create your own log.

1 Like