Karabiner Elements: Почему последовательность (или последовательность/партия) ключей, вызываемая в {…"to": …}, выполняется только каждый второй раз?

Я использовал оригинальное приложение Karabiner 10.22 и мог очень точно ограничить любые действия через Apple Accessibility Inspector для работы с определенными диалоговыми окнами.

Это больше невозможно с Karabiner Elements.

Итак, чтобы (в Safari) щелкнуть пункт контекстного меню «Информация об элементе» (который я использую очень часто), я попробовал этот код в «Сложных модификациях»:

 "to": [ { "pointing_button": "button2" },
         { "key_code": "e" },
         { "key_code": "return_or_enter"}  ]

Что действительно работало , но поочередно только открывало/показывало контекстное меню или фактически выполняло «Информацию об элементе».

Экспериментируя, я нашел обходной путь, который в основном работает для меня:

"parameters": { "basic.to_if_held_down_threshold_milliseconds": 50 }, 
"to":       [ { "pointing_button": "button2" } ],
"to_if_held_down":
            [ { "key_code": "e" },
              { "key_code": "return_or_enter"} ]

Мои вопросы:

Почему не все «команды» в первом примере кода выполняются в надлежащем порядке (или: только поочередно) и (более интересно:) как вы можете гарантировать, что каждая «команда» будет выполняться каждый раз?

Может быть, спросить на специализированном форуме Karabiner? groups.google.com/forum/#!forum/osx-карабин

Ответы (1)

Я думаю, что ваш обходной путь прекрасно демонстрирует причину: вы выбираете «Информацию об элементе» через графический интерфейс, и вызов контекстного меню может занять несколько миллисекунд. Это не проблема специально для Karabiner — если коды клавиш Eи returnотправляются мгновенно после щелчка правой кнопкой мыши, контекстное меню может быть еще не в фокусе, и они не будут направлены должным образом.

Короче говоря, если вы создаете макрос графического интерфейса, вам может потребоваться дождаться ответа графического интерфейса.

Как я вижу, есть три возможных решения:

  • просто добавьте короткую задержку, как вы сделали,
  • использовать альтернативный инструмент (например, Keyboard Maestro), который позволяет сделать паузу до тех пор, пока не будет выполнено определенное условие, или
  • использовать альтернативный метод активации желаемого результата, то есть что-то, что не зависит от графического пользовательского интерфейса на уровне пользователя, например AppleScript (хотя я не знаю, существует ли такая опция для этой конкретной цели).
Большое спасибо за ваш ответ, который касается первой части (почему) моего вопроса; вторая часть (how2) по-прежнему является наиболее интересной, чтобы получить отказоустойчивый метод (не зависящий от процессора, оперативной памяти и т. д.). Я вылечил «почему» с помощью моего обходного пути, но это не будет работать на каждом компьютере, может быть, даже не на моем, если одновременно работает слишком много приложений. Я голосую за ваш ответ на один, поэтому, если никто не найдет ответ на вопрос, как2, вы получите награду ... :-)
[ДОБАВЛЕНО СЛИШКОМ ПОЗДНО:] … если так еще «согласен» … :-)
@clemsamlang Я добавил свой ответ к своему ответу, так как он не очень хорошо вписывается в комментарий. :)
– Я ценю это… вы случайно не представляете, как можно заставить KE действительно ЖДАТЬ события графического интерфейса?
@clemsamlang Я не очень хорошо знаком со скриптовой стороной KE. Я должен был бы сделать больше исследований.
Я предлагаю, чтобы кто-то, читающий эту ветку, «поднял» ваш / Тимоти * ответ на +2: таким образом он получит половину «награды». Поскольку на важную (2-ю) часть моего вопроса нет ответа, я бы не хотел, чтобы эта ветка выглядела так, будто есть окончательный ответ…