Excluyendo algunas teclas de XGrabKeyboard

Question

Considere una aplicación en la que sea conveniente tomar el teclado cuando esté enfocado para capturar todos los comandos del administrador de ventanas (Alt + F4 y otras cosas) para su procesamiento. Ahora bien, esto tiene la desventaja de que el usuario no tiene forma de cambiar a otra aplicación o escritorio virtual a través del teclado cuando se agarra el teclado. Me gustaría tener una lista blanca definida por el usuario de la combinación de teclas (por ejemplo, las combinaciones de teclas para conmutar escritorios virtuales) que están excluidas de la captura.

Puedo pensar en dos posibles enfoques. Cuando llega un evento de clave incluido en la lista blanca, ya sea

1. De alguna manera, solicite a X que continúe con el procesamiento como de costumbre. Esto suena como una forma más natural de hacerlo, pero no puedo encontrar una manera de hacerlo, o
2. Desenganche el teclado y vuelva a enviar el evento a mano al administrador de ventanas para su procesamiento, sin embargo, no lo sé dónde enviarlo (¿la ventana raíz?) o si eso funcionaría.

¿Alguien puede completar los espacios en blanco? ¿Cualquier otra sugerencia?

Si no hay forma de excluir las llaves de un gancho, supongo que tendré que conformarme con tener una "tecla de escape" que desabroche el teclado cuando se presione. Sin embargo, el usuario tendrá que presionar tanto ese como el comando del administrador de ventanas, lo cual no es tan bueno.

Answer 1

No creo que haya una manera de hacerlo. Ninguno de los mecanismos funciona de la forma en que los necesitaría.

El enfoque 1 es algo así como lo que hace el administrador de ventanas si decide no interceptar un clic o una tecla, por ejemplo. Sin embargo, el WM está utilizando grabs "pasivos" en teclas particulares (XGrabKey = pasivo XGrabKeyboard = activo) y luego XAllowEvents(). XAllowEvents() no funciona con XGrabKeyboard(). también, cuando XAllowEvents con uno de los modos de Reproducción, el evento repetido omite todas las capturas pasivas en la ventana que tuvo la captura original y en todas sus ventanas principales. Las capturas de WM estarán en la ventana raíz, que siempre será una página principal, por lo que no hay forma de volver a la ventana raíz, lo mejor que puedo decir. Hacer XGrabKey en cada tecla posible sería una especie de psicópata de todos modos.

El acercamiento 2 tendría problemas de condición de carrera malos, porque otros eventos clave y de mouse podrían procesarse antes de poder volver a enviarlos, por lo que volvería a ordenar claves y enviaría eventos a ventanas destruidas y otras confusiones. Además, no hay una buena forma de enviar un evento clave. XSendEvent() es ignorado por muchos clientes (establece un indicador send_event en el evento que lo permite). La extensión XTest se puede usar, pero se puede deshabilitar en servidores X de producción y aún tiene problemas de condición de carrera.

Lo que probablemente necesitaría es una extensión de protocolo que le permita hacer un AllowEvents (mode = ReplayKeyboard) después de un GrabKeyboard y sin omitir pases pasivos en las ventanas principales.

Una advertencia es que no conozco todas las cosas alocadas que se pueden hacer con XKB y XInput2, así que tal vez haya algo en esas extensiones.

De todos modos, hasta donde sé, tiene que conformarse con la "clave de escape", aunque podría ser agradable que el servidor X y/o las especificaciones del administrador de ventanas tengan "conciencia de tipo VMWare/VNC-type-thing" , "eso no te ayudará en el corto plazo". Una extensión de especificación EWMH podría ser tan simple como una nueva _NET_WM_WINDOW_TYPE para vnc/vmware/cosas así y el administrador de ventanas podría reducir sus combinaciones de teclas o agregarles un modificador extra o algo así cuando esa ventana estuviera enfocada, por ejemplo.