KM isn't "recognizing" incremental versions of an application

[soundsgood]

I have a macro group containing macros that are to be triggered globally, except within one, particular application. I happen to be a beta-tester for its developer, and we're currently testing the latest version. (We're under NDA. Hence, the app pseudonym and redactions.)

In the Finder, each new build (version) has the build number in its name:

SuperApp 10b1
SuperApp 10b2
and so forth.

However, when I add the application to the macro group, KM displays only the primary version number, without the "b1" or "b2," etc. That's great and would actually be advantageous—if KM were truly ignoring the rest of the version number. But it isn't.

As a result, each time I install a new build, I encounter trigger conflicts, and then I remember that I have to add that new build to the macro group. But look at the result in the attached screenshot. There's an ever-growing list of identical application names.

But that's odd, because these are merely versions of the same application, not different applications. So it's baffling (and frustrating) that I keep having to add this application to the macro group, over and over again.

This seems like a bug. Since KM displays the name correctly each time, shouldn't it also recognize that these are the same application and behave accordingly?

[MartinPacker]

I’ve always considered this to be a “signature” problem - as in “how does KM detect this is the same app”? It varies from app to app.

Right now I’m beginning to develop macros for the betas of Drafts on Mac - which is updated by explicit download. Not to complain but I’m not confident subsequent betas will be recognised as the same app. I can live with that - particularly as the betas are relatively infrequent.

[soundsgood]

Thanks for chiming in.

I suppose my questions for Peter would be:

Is this something that can be adjusted in KM? Or is there something that application developers can do to avoid this problem?

[soundsgood]

Just bumping this in hopes of receiving a reply.

[ccstone]

Hey @soundsgood,

This is what Peter says about this issue:

Keyboard Maestro remembers applications based primarily on path, and secondarily on bundle ID.

If the application is not at the path Keyboard Maestro thinks it is (when it loads the macros), then it will search for the application based on the bundle ID.

So if you ensure there is only one version of the application on your Mac, and then launch Keyboard Maestro (editor), make any change to your macros, and then quit Keyboard Maestro, it should re-find it. If not, you may have to reselect the application in any macros or macro groups that reference it.

Unless you're keeping multiple versions of the same app on your system the maintenance shouldn't be that high.

-Chris

[soundsgood]

@ccstone

Hey @soundsgood,

This is what Peter says about this issue:

Keyboard Maestro remembers applications based primarily on path, and secondarily on bundle ID.

If the application is not at the path Keyboard Maestro thinks it is (when it loads the macros), then it will search for the application based on the bundle ID.

So if you ensure there is only one version of the application on your Mac, and then launch Keyboard Maestro (editor), make any change to your macros, and then quit Keyboard Maestro, it should re-find it. If not, you may have to reselect the application in any macros or macro groups that reference it.

Unless you're keeping multiple versions of the same app on your system the maintenance shouldn't be that high.

-Chris

Thanks. By necessity, I have to keep several versions of the app on my system. So, my previous questions still apply:

1. Is this something that can be adjusted in KM?
2. Or is there something that the application developers can do (i.e., naming conventions—either (a) in the Finder or (b) under the hood) to avoid this problem?

[ccstone]

@soundsgood

1. Is this something that can be adjusted in KM?

Hey @soundsgood,

Basically no.

Could it be done? Yes.

Will Peter spend the hours necessary to do it? Highly unlikely.

His ROA on this issue would be far in the red.

2. Or is there something that the application developers can do (i.e., naming conventions—either (a) in the Finder or (b) under the hood) to avoid this problem?

No again.

You have multiple apps on the same system with essentially (or exactly) the same name and same Application Bundle ID.

This will be a confusing situation for any apps that need to reference the betas. Multiple paths with the same Bundle ID.

The macOS basically handles this by considering the last app (with the same Bundle ID) you activated by hand to be the active app, but I've seen instance where it get's confused and activates a different version.

It looks like your best bet might be able to dig in and change the available application xml of your macro via AppleScript.

Actually this looks like it might not be too difficult:

tell application "Keyboard Maestro"
   tell macro group "BBEdit Group"
      set availableAppXML to available application xml
   end tell
end tell

Fully automating the process requires finding all your app versions and making sure they're all listed in the availableAppXML, but all of that is doable.

-Chris

[soundsgood]

@ccstone Are you an official spokesperson for Keyboard Maestro? Or for @peternlewis?

While I appreciate your input, your replies are speculative and appear contradictory, requiring me to have to spend additional time seeking clarification (and verification). While I appreciate your suggestions, I'd prefer not to have to reply to speculation about what Peter will or won't do.

When I asked, "Is this something that can be adjusted in KM?," you replied both "yes" and "no," which isn't helpful. It appears the answer to my specific question is "yes." Then, uynless you're an official representative, your speculation about what Peter will or won't do (irrespective of accuracy) isn't helpful.

To my second question, "Is there something that application developers can do…to avoid this problem?," first you say "no," and then you list steps outlining what could be done.

In my screenshot, KM keeps adding AppName 10 to the exclusion list, over and over again. Surely, there is in fact some way for KM to be instructed to exclude any application whose name contains the string "AppName 10."

For example, consider the rules that we can create in Apple Mail. You can ask Mail to perform tasks on any message the either starts with a text string, contains a text string, or ends with a text string. Similarly, in a macro group, KM could be instructed (if programmed to do so) to exclude any application that starts with "AppName" (ignoring the version number or any other text). It's clearly possible. That's the kind of enhancement about which I was inquiring, and I don't believe it would take "hours" to add "starts with," "contains," or "ends with" qualifiers to the code for a macro-group exclusion list. (Of course, whether Peter is inclined to do so is a separate matter.)

Thanks.

[ccstone]

@soundsgood

and then you list steps outlining what could be done.

Not by the developer – by you – using Keyboard Maestro – something you are in control of – something you can do now.

Lobby Peter all you want.

-Chris

[soundsgood]

@ccstone

Not by the developer – by you – using Keyboard Maestro – something you are in control of – something you can do now .

Lobby Peter all you want.

-Chris

There's already something I can do; it's what I've been doing, over and over again: Repeatedly adding each new version of the app to the macro group. The point of my questions was to ascertain if anything could be done to eliminate the extra steps. Again, I appreciate your suggestions, but that's even more work than the status quo.

Thanks.

[peternlewis]

@ccstone quoted me on what Keyboard Maestro does as far as handling versions of applications.

It remembers applications based on paths primarily. This is by design, since it allows Keyboard Maestro to differentiate between versions of the application (people frequently run multiple different versions of the same application and use different macros for both).

The displayed name is based on the display name of the application, so that is under the control of the developer of the application, hence why you are seeing “SuperApp 10” and not “SuperApp 10b2”.

If you keep the beta at the same path, then Keyboard Maestro should treat the new application the same as the old. Alternatively, if you ensure you have only a single copy of the application anywhere visible to Keyboard Maestro, then Keyboard Maestro should treat that as the definitive application.

However if you have multiple versions of the application with multiple paths, then Keyboard Maestro will treat them differently, by design.

@soundsgood

Just bumping this in hopes of receiving a reply.

I am currently hard at work on version 9.0, hence I have been less active on the forum (thankfully there are lots of great other folks here to help with most things).

@soundsgood

@ccstone Are you an official spokesperson for Keyboard Maestro? Or for @peternlewis?

@ccstone was not speaking for me, he was just giving his (very highly informed) opinion, together with the best advise on how to deal with it as it stands.

Might Keyboard Maestro someday handle applications differently? Sure, it is possible. But as stated, the current behaviour is very much by design to solve real world problems different from the ones of having multiple different applications that need to be treated as the same application.

As @ccstone said, it will be a huge amount of work (especially UI wise) to deal with allowing applications to be targeted in a more user-controlled way, the benefit of which is relatively limited, which makes it hard for the feature to percolate to the top of the todo list.