Jak naprawić przesunięcie wskaźnika myszy aplikacji Java w Awesome WM?

Jak reprodukować w Awesome WM v3.5.2 do 3.5.5 (jak dotąd):

1. Zainstaluj OpenJDK lub Oracle Java 7 . Ten błąd zaobserwowano w obu przypadkach.
2. Rozpocznij nową sesję Awesome WM z domyślną konfiguracją .
3. Uruchom jEdit lub PyCharm . Ten błąd zaobserwowano w obu przypadkach.
   • Poruszaj wskaźnikiem myszy i obserwuj, jak się zmienia w zależności od tego, czy najeżdżasz kursorem na kod, pliki projektu lub menu. To powinno działać normalnie.
   • Kliknij i zwolnij menu Plik , wejdź w jedno z podmenu i obserwuj, w jaki sposób pozycja bezpośrednio pod wskaźnikiem myszy jest cały czas skupiona.
4. Naciśnij kilkakrotnie Mod4+, Spaceaż uaktywni się układ pływający (aplikacja będzie prawie na pełnym ekranie) lub otwórz inną aplikację w tym samym znaczniku.

W tym momencie spodziewałbym się, że mysz będzie zachowywać się tak jak w przypadku „normalnych” aplikacji. Zamiast tego przestrzegam następujących zasad:

• Podczas klikania i poruszania się po menu za pomocą myszy, wskaźnik myszy i zaznaczone menu zostaną przesunięte w pionie od siebie, pozornie o tej samej liczbie pikseli, co wysokość paska stanu.
• Po najechaniu kursorem na różne elementy, jak poprzednio, ikona kursora zostanie ustawiona tak, jakby wskaźnik myszy był wyżej na ekranie. Na przykład po najechaniu kursorem na górną linię tekstu nie zobaczysz kursora tekstowego.

To tak, jakby coś nie wykryło zmiany współrzędnych okna.

Podobny, ale o wiele bardziej irytujący błąd występuje, gdy otwierasz inną aplikację w tym samym znaczniku - zachowanie myszy jest takie, jakby okno w ogóle się nie poruszyło.

Po przełączeniu innego znacznika, który ma już otwartą aplikację, „pulpit wirtualnej myszy” zostaje przeniesiony do lewego górnego rogu głównego ekranu .

Ponieważ błędy te zostały zaobserwowane zarówno w OpenJDK, jak i Oracle Java, w różnych aplikacjach Java, wydaje się bardzo prawdopodobne, że błąd dotyczy Awesome WM.

Powiązane pytanie , artykuł . Próbowałem _JAVA_AWT_WM_NONREPARENTINGi wmnamepoprawki, ale nie idź.

Z mojego doświadczenia wynika, że ​​do źródła należy dodać specjalne definicje dla menedżera okien.

Zdarzyło mi się to kilka lat temu w marcomenedżerze okien pulpitu MATE ; „poprawka” polegała na tym, aby marco udawał swój projekt nadrzędny, metacity, aby wykorzystać wbudowane poprawki JDK do metacity.

z src/core/display.c:

meta_prop_set_utf8_string_hint (the_display,
                                the_display->leader_window,
                                the_display->atom__NET_WM_NAME,
                                "Metacity (Marco)");

Ta poprawka cuchnie tym, co stało się z ciągiem agenta użytkownika w świecie przeglądarek internetowych, ale zadziałało dla mnie.

Ponadto arch wiki wspomina nawet o Awesome WM w sekcji o podszywaniu się pod inne menedżery okien, gdzie zaleca wmname:
https://wiki.archlinux.org/index.php/Java#Impersonate_another_window_manager

Możesz użyć wmname z suckless.org, aby JVM wierzyło, że używasz innego menedżera okien. Może to rozwiązać problem z renderowaniem GUI Java występujących w menedżerach okien, takich jak Awesome, Dwm lub Ratpoison.

$ wmname LG3D

Musisz ponownie uruchomić aplikację po wydaniu polecenia wmname.

Działa to, ponieważ JVM zawiera zakodowaną na stałe listę znanych menedżerów okien, które nie wymagają ponownego rodzicielstwa. Dla maksymalnej ironii niektórzy użytkownicy wolą podszywać się pod LG3D, menedżera okien, który nie nadaje się do ponownego rodzicielstwa, napisany przez Sun, w Javie.

Wydaje się, że jest to znany błąd związany z Javą w systemie Linux: https://netbeans.org/bugzilla/show_bug.cgi?id=227754

Na powyższym adresie URL można znaleźć obejście dla NetBeans IDE, obejście, które działa dla aplikacji Java, z której korzystam, to NIE maksymalizowanie aplikacji Java poprzez naciśnięcie przycisku maksymalizacji, ale ręczna zmiana rozmiaru okna w celu uzyskania preferowanego rozmiaru. Podziel się informacjami, jeśli to ci pomoże, dziękuję!