Бесконечные l oop нажатий клавиш с i3 bindsym и xdotool - PullRequest
0 голосов
/ 17 апреля 2020

Я пытаюсь преобразовать firefox -ctrl-q-обходной путь для обработки Ctrl-Shift- C. Это потому, что я продолжаю использовать Ctrl-Shift- C в Firefox по ошибке и постоянно открываю Developer Tools все время становится утомительным. Firefox, что невероятно раздражает, не имеет никакого способа настройки ярлыков.

Настройка выглядит примерно так:

Сначала свяжите ключ в i3 со скриптом:

# i3 config
bindsym --release Control+Shift+c exec --no-startup-id ~/ctrl_c_map.sh

И сам скрипт выглядит так:

# This is the active window
W="$(xdotool getactivewindow)"

# Get window class
WM_CLASS="$(xprop -id "$W" | awk -F '"' '/WM_CLASS/{print $4}')"

# Succeed if the WM_CLASS is firefox
is_firefox() {
    [ "$WM_CLASS" == "firefox" ] || [ "$WM_CLASS" == "Firefox Developer Edition" ]
}

send_key() {
    keytosend=$1
    xdotool key --clearmodifiers --window "$W" "$keytosend"
}

if is_firefox; then
    # remap to copy (Ctrl+C)
    send_key ctrl+c
else
    # re-send original C-S-c as it was actually useful
    send_key ctrl+shift+c
fi

Это работает в Firefox - событие Ctrl-Shift- C перехватывается и перераспределяется в Ctrl- C, и любой выбранный текст копируется. Черт!

Однако, в любой другой программе (особенно в терминале, где Ctrl-Shift- C действительно полезен), есть проблема. Когда ключ ctrl+shift+c отправляется с использованием xdotool, i3 снова ловит его и снова запускает скрипт, вызывая бесконечное l oop, которое вы можете избежать, только нажав Ctrl / Shift. Более того, целевое окно никогда не получает свою клавишу Ctrl-Shift- C: оно бесконечно циркулирует между i3 и bash, но фактически никогда не приходит.

Как вы можете отправить то же самое связанный ключ из скрипта, запускаемого i3 bindsym, без бесконечного l oop?

Ответы [ 2 ]

1 голос
/ 22 апреля 2020

С Autokey

[Это не совсем ответ на вопрос (как остановить бесконечные циклы между xdotool и i3), но это более гибкая альтернатива, чем i3 bindsym [class="firefox"] Подход, если вам нужно выполнить больше логи c, которые могут отправить исходный ключ. Если вы знаете, что никогда не отправите оригинальный ключ, ответ @ meuh будет проще, и это то, что я сейчас использую.]

Добавьте новый скрипт в autokey. Чтобы полностью отключить ключ, оставьте скрипт пустым. Чтобы отправить Ctrl + C, достаточно просто:

# Send Ctrl-C instead of Ctrl-Shift-C
keyboard.send_keys('<ctrl>+c')

Установить горячую клавишу на <ctrl>+<shift>+c и фильтр окна соответствующим образом. В моем случае Navigator.firefox - это то, что он обнаружил с помощью встроенного инструмента.

Вот и все.

Вы можете добавить logi c к этому сценарию для отправки различных ключей, включая оригинальный ключ , (или ничего) к программе по мере необходимости.

с i3 / xdotool

Если вы никогда не отправите тот же ключ, что и триггер, и вы всегда Если вы хотите отправить тот же ключ замены, вы должны использовать ответ @ meuh. Вы также можете вызвать скрипт для отправки ключа, если требуемый ключ может отличаться (например, Ctrl + C in Firefox или Alt + C в какой-то другой программе).

Критически, как и в ответе @ meuh, вы используете фильтр class, чтобы не вызывать скрипт в любой момент, когда вы отправляете оригинал ключ. Это регулярное выражение, поэтому вы можете иметь несколько фильтров:

# i3/config
bindsym --release Control+Shift+c [class="(firefox|other_prog)"] exec ~/myscript.sh

Сам скрипт в основном такой же, как в вопросе, но он никогда не сможет вызвать send_key ctrl+shift+c, иначе он будет oop. Вы можете отправить любой другой ключ (если только вы не зацикливаетесь на странном аттракторе нескольких скриптов, но это ваша проблема!)

1 голос
/ 17 апреля 2020

Возможно, вы могли бы ограничить соответствие на Control+Shift+c, используя критерии, которые соответствуют просто firefox, что-то вроде

bindsym Control+Shift+c [class="Firefox"] exec xdotool key --clearmodifiers ctrl+c
...