Unable to update to the latest alpha version (Nothing happens when clicking install and restart when updating to alpha version); using the latest stable version.
System has been rebooted.
Describe the bug
Key sequences that are set up with specific conditions work only when the advanced configuration page is open. As soon as the configuration page is closed, the key sequences stop functioning.
For example, a key sequence is set to trigger the shortcut command + T when the key T is pressed in the browser, provided the focused element's role is AXWebArea. This sequence works as expected when the configuration page is open for debugging. However, it ceases to function once the configuration page is closed.
I've been using the trigger for a couple of days, and I'm noticing some inconsistencies. Sometimes the key sequence works just as I expect, but other times it doesn't seem to respect the trigger condition.
For instance, it should trigger Cmd + T only when the focused element isn't a textfield. However, there are times when it does this even if the focused element is a textfield. This indicates that the assigned action is working, but the condition doesn't always hold, even though it sometimes works correctly.
The issue often arises when the laptop wake up from sleep, and I already set to true for restart BTT after wake from sleep.
Currently, the temporary fix i discovered is that i need to invoke BTT window once which will make the trigger work correctly.
Could you help me figure out how to permanently fix this please? Thanks!
Detailed condition as code:
active_app_name == "Arc" AND (NOT (currently_pressed_keyboard_keys CONTAINS "56," OR currently_pressed_keyboard_keys CONTAINS "55," OR currently_pressed_keyboard_keys CONTAINS "58," OR currently_pressed_keyboard_keys CONTAINS "59,")) AND focused_window_x != 480 AND focused_window_y != 274 AND focused_window_width != 750 AND (NOT (focused_element_role == "AXComboBox" OR focused_element_role == "AXTextArea" OR focused_element_role == "AXTextField"))
Yes, I think that's a similar problem to the one I have.
It's probably not much use, but I've found out:
The problem seems to be with the (text) fields.
If what you want to do can be expressed only with the "subrole" (instead of "focused element role", then it works much better, but not perfectly.
It works perfectly if no fields are used at all (only window names etc). At the moment I do it like this. After all, I know in which field I use the key sequence. The disadvantage is of course that the same key sequence cannot do different things in different fields.
Hi @Andreas_Hegenberg . Not sure if this is relevant to BTT, but in Activity Monitor, I always notice there is a process called cursorUIViewService is not responding.
Also, the issue of assigned actions not respecting the advanced condition mentioned earlier seemed not limited to a particular app. For instance, i have a global action configured as follows:
The condition is: if pressed there's no active window for the current app after pressing command+w then perform command+h (to automatically hide the current app which ultimately switch focus to next app).
The action mostly working fine, but similiar to my earlier issue with Arc, some times it will proceed and perform command+h even there is indeed active window, i.e chrome closing tabs, it will hide the chrome even when the active window is not empty.
I am one step away from my perfect setup, looking forward to your advice. Thanks for your attention.
Cmd+w issue has been fixed, but the issue with Arc triggers persists
I realise the issue only happens after wake up from sleep.
It is not necessary to bring BTT window to the front, change focus to other window/app and change back to Arc also do the trick. i.e. Cmd+tab twice. And all triggers will work correctly until next time wake up from sleep.
The async delay you suggested unfortunately didn't fix this issue. What puzzles me the most is the fact that BTT is able to recognize the app == Arc rule, but not able to recoginze the focused element role != AXTextField rule.
@Andreas_Hegenberg Sorry, but that's not the problem. At least not for me. I'd like to explain exactly what the problem is, but unfortunately I can't. Maybe this observation will help. If the cursor changes from field A to field B, but nothing else changes, BTT often does not recognize this field change. The condition remains true or false (green or not) as it was before the field change.
However, if something else also changes too (except the field), for example the name of the window, then the new field is recognized. Does this help?
To exclude the possibility that it is just a Scrivener problem, I have also tried this with Devonthink, where the same problem occurs. Unfortunately, I don't know how it is with other apps ... but I can give it a try now.
the problem is BTT relies on notifications sent by the apps to update the focused element - an alternative would be to poll the state of the focused element, but that would obviously create more cpu usage.
All standard macOS apps should support these notifications because Apple implemented them in all standard UI elements. However some multiplatform apps might not support them correctly. It sounds like both Scrivener and Devonthink are such multiplatform apps.
One thing I could easily do is add an per-app option to switch between polling and notifications.
Do I understand correctly that if the cursor is in the "correct" field, it should not take longer than 1.5 s for BTT to recognize the field? Unfortunately, this is not the case.
Here the cursor is in the field "AXTextField". The condition is fulfilled. But BTT still shows the last field "AXOutline" ... no matter how long I wait.
Does this help?
