Mudlet: Error de ubicación de la ventana del géiser

Creo que el problema podría ser con getMainWindowSize() que se rompió con una actualización de Qt, lo que explicaría los síntomas de que no hemos tocado el núcleo de Geyser en años, pero que se rompió recientemente (cambio de versión de Qt). Vea si esa función es la culpable para usted.

Así es como se calcula: https://github.com/Mudlet/Mudlet/blob/development/src/TConsole.cpp#L2776

: +1: No estoy seguro de poder contribuir a esta discusión en este momento con mi RL tal como está, pero puedo agradecerle a @basooza por lo que creo que es un informe de problemas constructivo. Tengo la sensación de que Hay muchos detalles relevantes que serán útiles, especialmente para delimitar qué versiones manifestaron el problema primero ...

Solo quería agregar información aquí después de la prueba. La primera vez que ejecuto Mudlet en Windows 8.1 y la ubicación de mi ventana es incorrecta. Puedo ejecutar lua display (getMainWindowSize ()) y de hecho muestra valores incorrectos. Para solucionar esto, des-maximizo la ventana, luego arrastro la esquina inferior derecha para cambiar el tamaño de la ventana, luego la pongo de nuevo a maximizada.

También descubrí que puedes alternar la visibilidad de la barra de herramientas principal, ¡y eso también lo solucionará! Entonces, parece que cualquier cosa que afecte a MainWindowSize es suficiente para solucionar este problema. Me pregunto si podríamos como solución ocultar / mostrar rápidamente la visibilidad de la barra de herramientas principal o algo así. Eso probablemente lo solucionaría hasta que se resuelva el problema con QT.

¡Darle una oportunidad!

Tengo más información para proporcionar. en lugar de cambiar el tamaño de la ventana. simplemente puede presionar el botón de cierre de Mudlet en la esquina superior derecha y responder Sí para guardar el perfil. En el próximo lanzamiento, esta extraña ubicación no sucederá.

Básicamente, son todos los demás lanzamientos que ve este problema. Voy a arriesgarme con este nuevo descubrimiento y decir que podría no ser QT el responsable, de lo contrario, no se arreglaría / sería correcto en todos los demás lanzamientos. Supongo que tiene que ver con algo que se guarda en el perfil, tal vez comparar los datos del perfil de ambos estados arrojaría algo de luz.

Voy a ver si puedo depurar esto más lejos ...

Bueno, todavía no he profundizado en el proceso de averiguar por qué sucede esto, pero con el uso continuo de Mudlet he descubierto cómo reproducirlo cada vez. Primero, parece haber varias cosas que pueden desencadenar este error, todas parecen estar relacionadas con problemas con la carga / guardado del perfil correctamente. Este en particular es cómo encontré reproducirlo cada vez.

En un sistema Windows, primero tenga la configuración del menú juegos-> Jugar "Abrir perfil al iniciar Mudlet" sin marcar. Para hacerlo, vaya al menú Juegos -> Jugar, desmarque la casilla y presione conectar. Una vez que se abre el perfil, puede cerrar Mudlet, guardar el perfil y luego lanzarlo nuevamente.

En el punto, el mudlet debe configurarse para que no lance automáticamente un perfil.

Ahora aquí está la siguiente parte, si inicia Mudlet y luego en el campo "Nombre del personaje", ingrese un nombre de personaje diferente (como un carácter ALT). Y presione el botón "conectar". Verá que la ubicación de la ventana es incorrecta. En este punto, la forma más fácil de corregir el error es cerrar Mudlet, guardar el perfil y luego reiniciarlo. Si inicias sesión en el mismo personaje, el error desaparecerá.

Para reproducir el error, todo lo que tiene que hacer es cerrar mudlet e ingresar un nombre de personaje diferente nuevamente, y su espalda a la colocación incorrecta de la ventana, reiniciar y se corrigió.

Creo que he hecho un buen trabajo al describir cómo reproducir este error, pero si alguien tiene problemas para seguir lo que estoy diciendo, estaría feliz de hacer un video que me muestre reproduciendo este error. Sólo házmelo saber.

¿Podría el código que guarda el diseño de las ventanas (acoplado: mapeador / ventanas de usuario / barras de herramientas) simplemente estar bloqueado?

Siempre he tenido un poco claro cómo podría ser posible guardar los datos de diseño cuando podría haber varios perfiles cargados (cada uno posiblemente con un widget de mapeador acoplado, con sus propias barras de herramientas y con otras ventanas de usuario acopladas) y luego esperar cuando uno de esos perfiles se vuelve a cargar para que los datos de todos ellos se interpreten y luego también se respeten cuando se cargan un segundo o más perfiles ...

... por supuesto, cualquier, o bien, todas esas ventanas sub-puede ser atracado fusionado (?) En una ventana con pestañas atracado (efectivamente atracado en uno encima del otro) y luego lo hace el diseño / postular código de eso?

@TheFae , ¿lo

Solo agregaré a esto, que solo me sucede a mí en Windows y se puede reproducir fácilmente en Windows. Nunca he visto que esto suceda en Linux, no estoy seguro de por qué Linux está contento con el perfil, pero Windows no. Tan pronto como pueda tener algo de tiempo libre, haré todo lo posible para resolver esto, mi idea era comparar los datos del perfil entre una sesión en la que ocurre el error y una sesión en la que no ocurre y buscar discrepancias. Simplemente no he tenido tiempo suficiente para profundizar en esto todavía.

Comparé la configuración guardada del perfil y nada se ve diferente entre antes y después de la carga de mudlet cuando ocurre el error, me pregunto qué otros archivos podrían ser responsables, como windowLayout.dat (si este fuera un archivo xml, comparar sería fácil, jajaja )

sin embargo, ese archivo está codificado, por lo que no estoy seguro de cómo compararlo antes / después de @ vadi2 , ¿sabe cómo puedo ver el contenido de este archivo antes / después de una carga cuando se produce el error? Realmente me gustaría rastrear y corregir este error.

@itsTheFae , ¿lo

@xekon ese archivo se agregó en Mudlet 3.2 cuando las ventanas de usuario comenzaron a recordar su posición: https://www.mudlet.org/2017/06/mudlet-3-2

¿Quiere probar si este problema existe en Mudlet 3.1 y 3.2?

En 3.1, mi perfil no se carga de la misma manera que yo también, supongo que la ubicación de la ventana se manejó de manera diferente en ese momento.

Sin embargo, según la primera publicación de este informe, mencionaron que 3.10.1 no tenía el problema. He podido reproducir el error al 100% cada vez y puedo confirmar que no existía es 3.10.1

Continué probando hacia arriba desde: 3.11, 3.11.1, 3.12, y finalmente 3.13 me mostró el error.

así que para probar más, decidí intentar degradarlo para comenzar con 3.12. y el error está presente, aunque cuando actualicé gradualmente de 3.11 a 3.12 no sucedió.

así que bajé aún más a 3.11.1 error todavía allí.

siguiente 3.11, el error sigue ahí.

siguiente 3.10.1 y finalmente el error se aclaró.

para resumir 3.10.1 no parece tener el error en absoluto.

Después de eso, puede actualizar de 3.10.1 a 3.11, 3.11.1 o 3.12 sin experimentar el error, pero tan pronto como actualice a 3.13, experimentará el error.

Después de haber experimentado el error con 3.13 o posterior, la única forma de eliminarlo por completo es degradarlo a 3.10.1 (3.11, 3.11.1 o 3.12 no eliminará el error hasta que baje por primera vez hasta 3.10. 1)

Mi intuición es que algo en el archivo windowLayout.dat se está guardando incorrectamente. (y de alguna manera esto no afecta a Linux, pero sí afecta a Windows).

¿Puede intentar borrar windowLayout.dat entre actualizaciones 3.10.1 - 3.13?

Si borro el archivo windowLayout.dat, el error se presenta de inmediato, con 3.11-3.13.

Parece que 3.10.1 fue la última versión que no mostró el error.

Así que 3.11 es la versión poco fiable. https://www.mudlet.org/2018/07/mudlet-3-11-quality-improvements-all-around ¿Hay notas de la versión y https://github.com/Mudlet/Mudlet/compare/Mudlet- 3.10.1 ... Mudlet-3.11.0 es la diferencia (desafortunadamente mucho ruido cuando eliminamos 3rdparty/zziplib no utilizados)

¿100% seguro de que funciona bien con Mudlet-3.10.0? Fue entonces cuando cambiamos de Qt 5.6 a 5.11 (que todavía usamos hasta el día de hoy). Podría haber sido un culpable allí y no en el código de Mudlets. Es lo que sospeché originalmente en https://github.com/Mudlet/Mudlet/issues/2076#issuecomment -432114672

Sí, 3.10.1 no tiene problemas.

Estoy de acuerdo en que sea Qt, excepto que el error solo ocurre cada dos lanzamientos cuando se cambia el nombre de personaje utilizado para acceder a un perfil, lo que sugiere que tiene algo que ver con cómo se guardan las cosas ... Por eso quería profundizar en el valores almacenados en windowLayout.dat

También podría ser que la versión más nueva de Qt guarde / cargue valores de manera diferente a como lo hacía en la versión anterior de Qt, pero en cualquier caso necesito un punto de partida para profundizar y ver qué está pasando. Necesito poder verificar los valores que se utilizan frente a los valores que se almacenan y averiguar cuál es la causa raíz.

Tendré que intentar buscar en el código todas las apariciones de windowLayout.dat y ver si puedo encontrar la mejor manera de depurar esto :) (Estoy pensando un poco cuando guarda los valores en ese archivo, también hacer que almacene el valores a un archivo plano .txt o xml, para que pueda entrar allí y mirar)

Sí. Quizás jugar con https://wiki.mudlet.org/w/Manual : Miscellaneous_Functions # saveWindowLayout y https://wiki.mudlet.org/w/Manual : Miscellaneous_Functions # loadWindowLayout también dará algunos resultados.

Gracias a Caled on discord, descubrí que este error probablemente esté relacionado: https://github.com/Mudlet/Mudlet/issues/2023

Caled también dijo: "Además, mi solución ha sido crear el mapeador y agregarlo a GUIframe en el evento 'sysLoadEvent'. Por si acaso esa información también es útil"

Este ejemplo usa Jor'Mox GUIFrame y cuando el mapeador está habilitado, el error está presente:
bugged.zip

aquí hay un ejemplo libre de errores que tiene un mapeador:
bugfree.zip

aquí hay un gif que muestra el error en acción después de importar el script con errores (verá que en el lanzamiento posterior de este perfil deshabilito la carga del mapa, lo que parece evitar el error):

aquí hay un gif que muestra el funcionamiento correcto del script sin errores que incluso tiene un mapeador presente:

Con basooza help, conseguí que esto funcionara para que el error no sucediera. Parece que el error ocurre como resultado de moverse / interactuar con el mapa antes de que Mudlet se cargue por completo, y obviamente solo bajo ciertas condiciones porque tengo un ejemplo sin errores arriba.

La forma en que GUIFrame dibuja todos los elementos de la interfaz de usuario hace que el error del mapa sea muy obvio, pero si demora la interacción con el mapa hasta que mudlet esté completamente cargado, entonces no sucederá.

¡ADEMÁS! este error solo ocurre en Windows, lo que significa que Linux es lo suficientemente inteligente o, naturalmente, se carga más rápido, por lo que interactuar con el mapa no es un problema. Sin embargo, en Windows, debe retrasar la interacción o el movimiento del mapa durante unos 100 ms para evitar el error.

aquí la solución que se me ocurrió gracias a @basooza :
bugfix_final.zip

Otra cosa que notará en la captura de pantalla a continuación, imprimo () el resultado de getMainWindowSize () y puede ver que el error aún ocurre, pero que usar un tempTimer de al menos 100ms está solucionando el problema:

También para agregar a esto ... simplemente tener un tempTimer no es suficiente, porque probé un tiempo de 0.01 y eso no fue suficiente (10ms) pero 0.1 es suficiente (100ms)

@ vadi2 solicitó un script MUY simple para reproducir el error, aquí está:
bug-getMainWindowSize.zip

y una captura de pantalla que muestra la depuración de print ():

mapperContainer = Geyser.Container:new({x=-700,y=0,width=700,height="70%",name="mapperContainer"})

print('Before Geyser.Mapper:new: ' .. tostring(getMainWindowSize()))
mapper = Geyser.Mapper:new({name = "mapper", x = 0, y = 0, width = "100%", height = "100%"}, mapperContainer)
print('After Geyser.Mapper:new: ' .. tostring(getMainWindowSize()))

print('before 100ms tempTimer: ' .. tostring(getMainWindowSize()))
tempTimer(0.1, function()
    print('after 100ms tempTimer: ' .. tostring(getMainWindowSize()))
end)

Trabajando en este problema. Parecería que las barras de herramientas izquierda / derecha, que es donde suelen ir los botones fáciles, de alguna manera ganan ancho por un momento, y es por eso que se reduce aquí.

@basooza @xekon , compruebe si https://github.com/Mudlet/Mudlet/pull/2945 soluciona el problema que describe aquí. ¡Gracias!