Esclusione di alcune chiavi da XGrabKeyboard

Question

Considerare un'applicazione in cui è preferibile afferrare la tastiera quando è focalizzata per acquisire tutti i comandi di gestione finestre (Alt + F4 e quant'altro) per l'elaborazione. Ora, questo ha il rovescio della medaglia che l'utente non ha modo di passare a un'altra applicazione o desktop virtuale tramite la tastiera quando viene afferrata la tastiera. Mi piacerebbe avere una whitelist definita dall'utente della combinazione di tasti (ad esempio, le combinazioni di tasti per la commutazione di desktop virtuali) che sono esclusi dalla cattura.

Posso pensare a due possibili approcci. Quando arriva un evento chiave nella whitelist, sia

1. In qualche modo dire a X di continuare a processarlo come al solito. Sembra un modo più naturale di farlo ma non riesco a trovare un modo per farlo, oppure
2. Annulla la tastiera e invia nuovamente l'evento a mano al gestore di finestre per l'elaborazione, tuttavia non so dove spedirlo (la finestra radice?) o se funzionerebbe anche.

Qualcuno può compilare gli spazi vuoti su quelli? Qualche altro suggerimento?

Se non c'è modo di escludere chiavi da una presa, suppongo che dovrò accontentarmi di avere una "chiave di escape" che sblocca la tastiera quando viene premuto. L'utente dovrà premere sia quello che il comando di gestione della finestra, che però non è così bello.

Answer 1

Non credo che ci sia un modo per farlo. Nessuno dei meccanismi funziona come avresti bisogno di loro.

L'approccio 1 è una sorta di cosa fa il gestore di finestre se decide di non intercettare un clic o un tasto, ad esempio. Tuttavia, il WM utilizza graficamente "passive" su chiavi particolari (XGrabKey = passivo XGrabKeyboard = attivo) e poi XAllowEvents(). XAllowEvents() non funziona con XGrabKeyboard(). inoltre, quando esegui XAllowEvents con una delle modalità di riproduzione, l'evento ripetuto ignora tutte le prese passive sulla finestra che aveva la presa originale e su tutte le finestre principali. Le prese del WM saranno nella finestra radice che sarà sempre un genitore quindi non c'è modo di rivedere la finestra di root, meglio che posso dire. Fare XGrabKey su ogni possibile chiave sarebbe comunque una specie di psicopatico.

L'approccio 2 avrebbe avuto problemi di condizioni di competizione, poiché altri eventi chiave e del mouse potrebbero essere elaborati prima di poter essere nuovamente inviati, in modo da riordinare le chiavi e inviare eventi a finestre distrutte e altra confusione. Inoltre, non esiste un buon modo per inviare un evento chiave. XSendEvent() viene ignorato da molti client (imposta un flag send_event nell'evento che consente questo). L'estensione XTest può essere utilizzata ma può essere disabilitata sui server X di produzione e presenta ancora problemi di condizioni di competizione.

Quello che potrebbe essere necessario è un'estensione di protocollo che consente di eseguire un AllowEvents (modalità = ReplayKeyboard) dopo un GrabKeyboard e senza bypassare le acquisizioni passive sulle finestre padre.

Un avvertimento è che non conosco tutte le cose selvagge che possono essere fatte con XKB e XInput2, quindi forse c'è qualcosa in quelle estensioni.

In ogni caso, per quanto ne so, è necessario accontentarsi della "chiave di escape", anche se alla fine potrebbe essere bello che il server X e/o le specifiche del gestore di finestre abbiano "consapevolezza di tipo VMWare/VNC-thing" , "che non ti aiuterà a breve termine. Un'estensione specifica EWMH potrebbe essere semplice come un nuovo _NET_WM_WINDOW_TYPE per vnc/vmware/stuff-like-that e il window manager potrebbe ridurre le sue combinazioni di tasti o aggiungere un modificatore aggiuntivo a loro o qualcosa quando la finestra era focalizzata, per esempio.