Cómo reproducir en Awesome WM v3.5.2 a 3.5.5 (hasta ahora):
- Instalar OpenJDK u Oracle Java 7 . Este error se ha observado con ambos.
- Inicie una nueva sesión de Awesome WM con la configuración predeterminada .
- Inicie ya sea jEdit o PyCharm . Este error se ha observado con ambos.
- Mueva el puntero del mouse y observe cómo cambia en función de si se desplaza sobre el código, los archivos de proyecto o los menús. Esto debería funcionar normalmente.
- Haga clic y suelte en el Archivo menú, ingrese a uno de los submenús y observe cómo el elemento directamente debajo del puntero del mouse está enfocado todo el tiempo.
- Presione Mod4 +Espacio repetidamente hasta que el diseño flotante está activado (la aplicación estará casi a pantalla completa) o abra otra aplicación en la misma etiqueta.
En este punto, esperaría que el mouse se comportara como lo hace con las aplicaciones "normales". En cambio, observo lo siguiente:
- Al hacer clic y navegar por los menús con el mouse, el puntero del mouse y el elemento del menú enfocado estarán desplazados verticalmente entre sí, aparentemente con la misma cantidad de píxeles que la altura de la barra de estado.
- Al pasar el cursor sobre varios elementos como antes, el icono del cursor se configurará como si el puntero del mouse estuviera más arriba en la pantalla. Por ejemplo, al pasar el cursor sobre la línea superior de texto, no verá un cursor de texto.
Es como si algo no detectara que las coordenadas de la ventana han cambiado.
Un error similar pero mucho más molesto ocurre cuando abre otra aplicación en la misma etiqueta – el comportamiento del mouse es como si la ventana no se hubiera movido en absoluto.
Cuando alternas otra etiqueta que ya tiene una aplicación abierta – el “escritorio del mouse virtual” se mueve a la parte superior izquierda de la pantalla principal .
Dado que estos errores se han observado tanto en OpenJDK como en Oracle Java, con diferentes aplicaciones Java, parece muy probable que el error esté en Awesome WM.
Pregunta relacionada, artículo. Probé el _JAVA_AWT_WM_NONREPARENTING y wmname arregla, pero no funciona.
Respuesta aceptada:
Según mi experiencia, debe agregar definiciones especiales a la fuente para el administrador de ventanas.
Me pasó esto hace un par de años en el marco del escritorio MATE gestor de ventanas; la 'solución' fue hacer que marco pretendiera ser su proyecto principal, metacity, para utilizar las correcciones integradas de JDK para metacity.
de src/core/display.c :
meta_prop_set_utf8_string_hint (the_display,
the_display->leader_window,
the_display->atom__NET_WM_NAME,
"Metacity (Marco)");
Esta solución huele a lo que sucedió con la cadena de agente de usuario en el mundo de los navegadores web, pero funcionó para mí.
Relacionado:¿comando Ubuntu runuser?
Además, la arch wiki incluso menciona Awesome WM en la sección sobre hacerse pasar por otros administradores de ventanas, donde recomienda wmname :
https://wiki.archlinux.org/index.php/Java#Impersonate_another_window_manager
Puede usar el wmname de suckless.org para hacer que la JVM crea que
está ejecutando un administrador de ventanas diferente. Esto puede resolver un problema de representación
de las GUI de Java que se producen en administradores de ventanas como Awesome o Dwm o
Ratpoison.
$ nombre de usuario LG3D
Debe reiniciar la aplicación en cuestión después de ejecutar el comando wmname
.
Esto funciona porque la JVM contiene una lista codificada de administradores de ventanas conocidos,
que no son padres. Para mayor ironía, algunos usuarios prefieren
hacerse pasar por LG3D, el administrador de ventanas sin re-parentalidad escrito por
Sun, en Java.