Exclusion de certaines clés de XGrabKeyboard

Question

Considérons une application dans laquelle il est souhaitable de saisir le clavier lorsqu'il est focalisé afin de capturer toutes les commandes du gestionnaire de fenêtres (Alt + F4 et autres commandes) pour le traitement. Maintenant, cela a l'inconvénient que l'utilisateur n'a aucun moyen de passer à une autre application ou un bureau virtuel via le clavier lorsque le clavier est saisi. Je voudrais avoir une liste blanche définie par l'utilisateur de la combinaison de touches (par exemple, les combinaisons de touches pour le changement de bureaux virtuels) qui sont exclus de la saisie.

Je peux penser à deux approches possibles. Lorsqu'un événement de clé en liste blanche arrive, soit

1. D'une manière ou d'une autre, dites à X de continuer à le traiter comme d'habitude. Cela ressemble à une façon plus naturelle de le faire, mais je ne peux pas trouver un moyen de le faire, ou
2. Décrochez le clavier et renvoyez l'événement à la main au gestionnaire de fenêtre pour le traitement, mais je ne sais pas où l'envoyer (la fenêtre racine?) ou si cela fonctionnerait même.

Est-ce que quelqu'un peut remplir les espaces vides sur ceux-ci? D'autres suggestions?

S'il n'y a aucun moyen d'exclure les clés d'un grappin, je suppose que je vais devoir me contenter d'avoir une "touche d'échappement" qui déverrouille le clavier quand on appuie dessus. L'utilisateur devra appuyer à la fois sur cette commande et sur la commande du gestionnaire de fenêtres, ce qui n'est pas aussi agréable.

Answer 1

Je ne pense pas qu'il existe un moyen de le faire. Aucun des mécanismes ne fonctionne exactement comme vous en auriez besoin.

L'approche 1 est une sorte de ce que fait le gestionnaire de fenêtres s'il décide de ne pas intercepter un clic ou une clé par exemple. Cependant, le WM utilise des saisies "passives" sur des clés particulières (XGrabKey = passif XGrabKeyboard = actif) et ensuite XAllowEvents(). XAllowEvents() ne fonctionne pas avec XGrabKeyboard(). De même, lorsque vous utilisez XAllowEvents avec l'un des modes de relecture, l'événement relu contourne toutes les saisies passives de la fenêtre contenant la capture d'origine et toutes les fenêtres parentes. Les grabbs de WM seront sur la fenêtre racine qui sera toujours un parent donc il n'y a aucun moyen de rejouer à la fenêtre racine, mieux que je puisse dire. Faire XGrabKey sur toutes les clés possibles serait une sorte de psycho de toute façon. L'approche 2 aurait de mauvais problèmes de condition de course, car d'autres événements de clé et de souris pourraient être traités avant que vous puissiez renvoyer, ainsi vous réorganiseriez les clés et enverriez des événements aux fenêtres détruites et à d'autres confusions. De plus, il n'y a pas de bon moyen d'envoyer un événement clé. XSendEvent() est ignoré par de nombreux clients (il définit un indicateur send_event dans l'événement le permettant). L'extension XTest peut être utilisée mais peut être désactivée sur les serveurs X de production et présente toujours des problèmes de condition de concurrence. Ce dont vous auriez probablement besoin est une extension de protocole qui vous permet de faire un AllowEvents (mode = ReplayKeyboard) après un GrabKeyboard et sans contourner les saisies passives sur les fenêtres parentes. Un inconvénient est que je ne connais pas toutes les choses qui peuvent être faites avec XKB et XInput2, donc peut-être qu'il y a quelque chose dans ces extensions. Quoi qu'il en soit, pour autant que je sache, vous devez vous contenter de la "touche d'échappement", mais il sera peut-être intéressant pour le serveur X et/ou les spécifications du gestionnaire de fenêtres d'avoir "VMWare/VNC », cela ne vous aidera pas à court terme. Une extension de spécification EWMH pourrait être aussi simple qu'une nouvelle _NET_WM_WINDOW_TYPE pour vnc/vmware/stuff-like-that et le gestionnaire de fenêtres pourrait réduire ses raccourcis clavier ou ajouter un modificateur supplémentaire à eux ou quelque chose quand cette fenêtre était focalisée, par exemple.