Сегодня разбирал очень интересный пограничный случай в BetterTouchTool: одна и та же конфигурация «крутить колесо мыши внизу экрана, чтобы регулировать громкость SoundSource» нормально работает, когда на переднем плане QQ, Finder и другие окна, но не срабатывает, когда на переднем плане Chrome.
Симптомы
- В Global есть два триггера Normal Mouse:
996/997. - В BTT эти два кода соответствуют прокрутке колеса мыши вниз / вверх.
- У этих двух глобальных триггеров условие
mouse_pos_percent_y < -98, то есть указатель находится внизу экрана. - В Chrome дополнительно есть несколько app-specific
996/997:- Cmd+scroll — масштабирование страницы
- прокрутка колесом вверху — переключение вкладок
- прокрутка колесом у левого края — Page Up / Page Down
- В QQ нет app-specific
996/997.
Интуитивно кажется, что эти триггеры в Chrome не конфликтуют с нижним триггером громкости: условия по верхней области, левому краю, модификатору Cmd и положению внизу не пересекаются. Но на практике, когда Chrome на переднем плане, глобальный нижний триггер колеса срабатывает нестабильно или не срабатывает вовсе, а когда на переднем плане QQ — всё нормально.
Вывод
Дело не в том, что Chrome перехватывает колесо, и не в том, что условия по положению действительно конфликтуют, а в стратегии сопоставления высокочастотных mouse trigger в BTT.
Когда у текущего app уже есть однотипный Normal Mouse / Mouse Wheel trigger, BTT сначала переходит на слой app-specific правил текущего приложения. Даже если условия этих app-specific правил не совпадают, BTT не обязательно продолжит проходить по однотипным trigger в Global.
Автор BTT Andreas тоже упоминал похожую проблему: mouse triggers не выполняют полный циклический поиск по всем потенциально подходящим trigger между app ради проверки условий — в основном из соображений производительности. Похожий вопрос см.:"For all Apps" Trigger stopps working when Firefox specific Trigger is configured - Bugs or Unexpected Behavior - BetterTouchTool Community
Способ исправления
Минимальное исправление: скопировать нижний триггер громкости и для Chrome, чтобы он попал на собственный уровень правил Chrome 996 / 997.
То есть:
- В Global оставить нижний триггер громкости колесом прокрутки для приложений, у которых нет app-specific конфигурации колеса прокрутки.
- Для Chrome отдельно добавить такой же нижний триггер громкости колесом прокрутки, чтобы он находился на одном уровне с переключением вкладок сверху, перелистыванием у левого края и масштабированием через Cmd+колесо прокрутки в Chrome.
В долгосрочной перспективе более чистая структура такая: если какой-то тип ввода — это часто используемый mouse wheel trigger, лучше по возможности не смешивать app-specific правила и Global fallback, а поместить связанные правила на один уровень и различать их по условиям: положению, клавишам-модификаторам и приложению.
Мысли
Сейчас BTT очень мощный, но при этом всё более громоздкий. Такое поведение по сути является компромиссом ради производительности: чтобы не перебирать множество app/global условий при каждом событии колеса прокрутки, он жертвует частью интуитивной согласованности «наследуемой конфигурации».
Эта ловушка довольно незаметная, потому что с точки зрения логики условий конфликта вообще нет, но с точки зрения уровней сопоставления BTT конфликт уже есть.