No, that option is not enabled, but it behaves the same if that option is enabled. Note, the computer in question is managed by my employer and is a couple of OS versions behind. It is using macOS Sierra 10.12.6.
I just tested this in my personal computer, running macOS Mojave 10.14.3, and where I have set "Always use old keyboard shortcut implementation" due to other issues. In this case it works most of the time, but here is one example where the window name evaluates incorrectly (BTT is reporting the name of the underlying window).
Ah interesting, I have not tested this feature on 10.12 yet will do that soon. I might however need to disable it on older macOS versions if it's not working there - it's possible some of the APIs were not completely available in 10.12.
in the screenshot I think it indicates that there is a little issues in Outlook as it shows the window title as (null) in the outlook window. Most likely Outlook is not telling BTT that the window name title has changes. But I'll see if I can add a test for null values.
On the older OS, BTT 2.701 is evaluating the conditions correctly, as evidenced by the green text. The problem seems strictly that the evaluation of the condition is not controlling whether the command-W keystroke is intercepted.
Regarding the null in the window title (note: it was actually "Untitled • (null)" in the example above), it does not seem to be related to null in the title. Here I reproduced this without that. But I agree this may be an Outlook bug.
Thank you! Maybe the shortcut issue is not strictly related to the conditional activation groups then. Maybe on 10.12. there is some general problem with the keyboard shortcut interception. I'll setup a virtual machine later and test!
Maybe also try whether enabling the old keyboard shortcut implementation changes the behavior on 10.12.
I did the following tests on 10.12.
-
Added the same shortcut to disable Command-W associated with a single application. This worked correctly. Command-W was suppressed only within that one application. //edit: this was an unconditional shortcut.
-
Tried the conditional activation group with "Always use old keyboard shortcut implementation". This worked UNTIL I encountered a situation within Outlook that satisfied the condition. Once that happened, Command-W was suppressed everywhere regardless whether the condition was satisfied. In fact, each time I toggle "Always use old keyboard shortcut implementation" Command-W works correctly across apps temporarily until the condition is satisfied one time, then Command-W is suppressed everywhere. It does not matter which keyboard shortcut implementation is being used, apparently.
There has been a significant bugfix in 2.716 affecting conditional activation groups and keyboard shortcuts. Possibly this bug has also influenced the behavior you encountered. Would be great if you'd check again with that version. I also did basic tests on 10.12, but could reproduce it (but still without Outlook, maybe I will need to install that to see)
There is still a problem with BTT 2.716 on OS 10.12.6.
Specifically, as previously reported: "The problem seems strictly that the evaluation of the condition is not controlling whether the command-W keystroke is intercepted."
It does not matter whether the conditional activation group is associated with Outlook or a different app. The conditions are evaluated correctly now.
But, the keystroke mapping is not dependent on whether the condition is actually true.
Also, this previously reported behavior is still present:
" 2. Tried the conditional activation group with "Always use old keyboard shortcut implementation". This worked UNTIL I encountered a situation within Outlook that satisfied the condition. Once that happened, Command-W was suppressed everywhere regardless whether the condition was satisfied. In fact, each time I toggle "Always use old keyboard shortcut implementation" Command-W works correctly across apps temporarily until the condition is satisfied one time, then Command-W is suppressed everywhere. It does not matter which keyboard shortcut implementation is being used, apparently."
Damn, this definitely works fine on my 10.12 machine. I think then it's probably not the macOS version but some other setting that's influencing this behavior.
Is there a config file I can send you?
Yep:
Go to the about tab in BTT, then click "Export Debug Information", this will create a folder called "BetterTouchToolDebug" on your desktop. Sending that to andreas@folivora.ai should allow me to restore your settings on my machine (although it won't include system settings).
