Comment reproduire dans Awesome WM v3.5.2 à 3.5.5 (jusqu'à présent) :
- Installez OpenJDK ou Oracle Java 7 . Ce bogue a été observé avec les deux.
- Démarrer une nouvelle session Awesome WM avec la configuration par défaut .
- Démarrez soit jEdit ou PyCharm . Ce bogue a été observé avec les deux.
- Déplacez le pointeur de la souris et observez comment il change selon que vous survolez du code, des fichiers de projet ou des menus. Cela devrait fonctionner normalement.
- Cliquez et relâchez sur le Fichier menu, entrez dans l'un des sous-menus et observez comment l'élément directement sous le pointeur de la souris est focalisé tout le temps.
- Appuyez sur Mod4 +Espace à plusieurs reprises jusqu'à la mise en page flottante est activé (l'application sera presque en plein écran) ou ouvrir une autre application dans la même balise.
À ce stade, je m'attendrais à ce que la souris se comporte comme elle le fait avec les applications "normales". Au lieu de cela, j'observe ce qui suit :
- Lorsque vous cliquez et naviguez dans les menus avec la souris, le pointeur de la souris et l'élément de menu ciblé seront décalés verticalement les uns des autres, apparemment au même nombre de pixels que la hauteur de la barre d'état.
- Lorsque vous survolez divers éléments comme auparavant, l'icône de curseur sera réglé comme si le pointeur de la souris était plus haut sur l'écran. Par exemple, en survolant la première ligne de texte, vous ne verrez pas de curseur de texte.
C'est comme si quelque chose ne détectait pas que les coordonnées de la fenêtre avaient changé.
Un bogue similaire mais beaucoup plus ennuyeux se produit lorsque vous ouvrez une autre application dans la même balise – le comportement de la souris est comme si la fenêtre n'avait pas bougé du tout.
Lorsque vous basculez vers une autre balise qui a déjà une application ouverte - le "bureau de la souris virtuelle" est déplacé vers le haut gauche de l'écran principal .
Étant donné que ces bogues ont été observés à la fois dans OpenJDK et Oracle Java, avec différentes applications Java, il semble très probable que le bogue se trouve dans Awesome WM.
Question connexe, article. J'ai essayé le _JAVA_AWT_WM_NONREPARENTING et wmname correctifs, mais non.
Réponse acceptée :
D'après mon expérience, vous devez ajouter des définitions spéciales à la source du gestionnaire de fenêtres.
Cela m'est arrivé il y a quelques années dans le marco du bureau MATE gestionnaire de fenêtres ; le "correctif" consistait à faire passer marco pour son projet parent, metacity, afin d'utiliser les correctifs intégrés du JDK pour metacity.
depuis src/core/display.c :
meta_prop_set_utf8_string_hint (the_display,
the_display->leader_window,
the_display->atom__NET_WM_NAME,
"Metacity (Marco)");
Ce correctif rappelle ce qui est arrivé à la chaîne de l'agent utilisateur dans le monde des navigateurs Web, mais cela a fonctionné pour moi.
Connexe :commande Ubuntu runuser ?
De plus, l'arch wiki mentionne même Awesome WM dans la section sur l'usurpation d'identité d'autres gestionnaires de fenêtres, où il recommande wmname :
https://wiki.archlinux.org/index.php/Java#Impersonate_another_window_manager
Vous pouvez utiliser le wmname de suckless.org pour faire croire à la JVM que vous utilisez un autre gestionnaire de fenêtres. Cela peut résoudre un problème de rendu
des interfaces graphiques Java survenant dans les gestionnaires de fenêtres comme Awesome ou Dwm ou
Ratpoison.$ wmname LG3D
Vous devez redémarrer l'application en question après avoir émis la commande wmname
.Cela fonctionne car la JVM contient une liste codée en dur de gestionnaires de fenêtres connus,
non reparents. Pour un maximum d'ironie, certains utilisateurs préfèrent
usurper l'identité de LG3D, le gestionnaire de fenêtres non-reparenting écrit par
Sun, en Java.