Исключая некоторые ключи из XGrabKeyboard

Question

Рассмотрите приложение, где желательно захватить клавиатуру, когда она сфокусирована, чтобы захватить все команды менеджера окон (Alt + F4 и еще ничего) для обработки. Теперь это имеет недостаток, что у пользователя нет возможности переключиться на другое приложение или виртуальный рабочий стол с клавиатуры при захвате клавиатуры. Я хотел бы иметь пользовательский белый список комбинации клавиш (например, комбинации клавиш для переключения виртуальных рабочих столов), которые исключаются из захвата.

Я могу думать о двух возможных подходах. Когда приходит событие с клюшкой, либо

1. Как-то сказать X продолжить обработку, как обычно. Это звучит как более естественный способ сделать это, но я не могу найти способ сделать это, или
2. Снимите клавиатуру и повторно отправьте событие вручную диспетчеру окна для обработки, однако я не знаю куда отправить его (корневое окно?), или это будет работать.

Может ли кто-нибудь заполнить пробелы на них? Любые другие предложения?

Если у вас нет возможности исключить ключи из захвата, я думаю, мне придется согласиться на «ключ перехода», который отжимает клавиатуру при нажатии. Пользователь должен будет нажать и то, и затем команду диспетчера окон, хотя это не так приятно.

Answer 1

Я не думаю, что есть способ сделать это. Ни один из механизмов не работает так, как вам нужно.

Подход 1 - это то, что делает оконный менеджер, если он решает не перехватывать клик или ключ, например. Тем не менее, WM использует «пассивный» захват на определенных клавишах (XGrabKey = пассивный XGrabKeyboard = активный), а затем XAllowEvents(). XAllowEvents() не работает с XGrabKeyboard(). также, когда вы XAllowEvents с одним из режимов воспроизведения, проигранное событие обходит все пассивные захваты в окне, которое имело первоначальный захват и во всех его родительских окнах. Гнезда WM будут в корневом окне, которое всегда будет родителем, поэтому нет способа воспроизвести его в корневом окне, лучше всего я могу сказать. Выполнение XGrabKey на каждом возможном ключе было бы во что бы то ни стало.

Подход 2 имел бы проблемы с плохой гоночной ситуацией, потому что другие события с ключами и мышами могли быть обработаны до того, как вы сможете отправить их повторно, поэтому вы изменили порядок ключей и отправили события в разрушенные окна и другую путаницу. Кроме того, нет хорошего способа отправить ключевое событие. XSendEvent() игнорируется многими клиентами (он устанавливает флаг send_event в событии, допускающем это). Расширение XTest можно использовать, но может быть отключено на серверах X производства и все еще имеет проблемы с условиями гонки.

Возможно, вам понадобится расширение протокола, позволяющее выполнять AllowEvents (mode = ReplayKeyboard) после GrabKeyboard и без обхода пассивных захватов в родительских окнах.

Одно из предостережений заключается в том, что я не знаю всех диких вещей, которые могут быть сделаны с XKB и XInput2, поэтому, возможно, в этих расширениях есть что-то.

В любом случае, насколько я знаю, вы должны согласиться на «escape-ключ», хотя в конечном итоге это может быть полезно для X-сервера и/или спецификаторов оконного администратора, чтобы иметь «понимание типа VMWare/VNC-типа» , «это не поможет вам в краткосрочной перспективе. Расширение спецификации EWMH может быть таким же простым, как новый _NET_WM_WINDOW_TYPE для vnc/vmware/stuff-like-that, и диспетчер окон может уменьшить свои привязки клавиш или добавить к ним дополнительный модификатор или что-то, когда это окно было сфокусировано, например.