Mudlet: Bug de placement de fenêtre Geyser

Je pense que le problème pourrait être avec getMainWindowSize() qui a été cassé avec une mise à niveau de Qt, ce qui expliquerait les symptômes du fait que nous n'avons pas touché le noyau de Geyser depuis longtemps mais qu'il s'est cassé récemment (changement de version de Qt). Voyez si cette fonction est le coupable pour vous.

Voici comment il est calculé: https://github.com/Mudlet/Mudlet/blob/development/src/TConsole.cpp#L2776

: +1: Je ne suis pas sûr de pouvoir contribuer à cette discussion pour le moment avec mon RL tel quel, mais puis-je simplement remercier @basooza pour ce que je pense être un rapport constructif - j'ai le sentiment qu'il y en a beaucoup de détails pertinents qui seront utiles, en particulier pour déterminer quelles versions ont manifesté le problème en premier ...

Je voulais juste ajouter quelques informations ici après le test. Lorsque je lance Mudlet pour la première fois sous Windows 8.1 et que mon emplacement Windows est incorrect. Je peux exécuter l'affichage lua (getMainWindowSize ()) et il affiche en effet des valeurs incorrectes. Pour résoudre ce problème, je ne maximise pas la fenêtre, puis je fais glisser le coin inférieur droit pour redimensionner la fenêtre, puis je la remets en position agrandie.

J'ai également constaté que vous pouvez basculer la visibilité de la barre d'outils principale, et cela le corrigera également! Il semble donc que tout ce qui affecte MainWindowSize soit suffisant pour résoudre ce problème. Je me demande si nous pourrions, comme solution de contournement, masquer / afficher rapidement la visibilité de la barre d'outils principale ou quelque chose. Cela résoudrait probablement le problème jusqu'à ce que le problème avec QT soit résolu.

Essayez!

J'ai plus d'informations à fournir. au lieu de redimensionner la fenêtre. vous pouvez simplement appuyer sur le bouton de fermeture de Mudlet dans le coin supérieur droit et répondre Oui pour enregistrer le profil. Au prochain lancement, ce placement étrange ne se produira pas.

Donc, fondamentalement, c'est à chaque autre lancement que vous voyez ce problème. Je vais m'éclipser avec cette nouvelle découverte et dire que ce n'est peut-être pas QT qui est responsable, sinon pourquoi il ne serait pas corrigé / correct à chaque autre lancement. Je suppose que cela a à voir avec quelque chose qui est enregistré dans le profil, peut-être que comparer les données de profil des deux états éclairerait un peu.

Je vais voir si je peux déboguer cela plus loin ...

Eh bien, je n'ai pas encore creusé dans le processus pour comprendre pourquoi cela se produit, mais avec une utilisation continue de Mudlet, j'ai compris comment le reproduire à chaque fois. Premièrement, il semble y avoir plusieurs choses qui peuvent déclencher ce bogue, elles semblent toutes liées à des problèmes de chargement / enregistrement correct du profil. Celui-ci est juste la façon dont j'ai trouvé pour le reproduire à chaque fois.

Sur un système Windows, commencez par décocher le paramètre du menu Jeux-> Jouer "Ouvrir le profil au démarrage de Mudlet". Pour ce faire, accédez au menu Jeux -> Jouer, décochez la case et appuyez sur se connecter. Une fois le profil ouvert, vous pouvez fermer Mudlet, enregistrer le profil, puis relancer mudlet.

À ce stade, le mudlet doit être configuré de manière à ne pas lancer automatiquement un profil.

Maintenant, voici la partie suivante, Si vous lancez Mudlet, puis dans le champ "Nom du personnage" remplissez un nom de personnage différent (tel qu'un caractère ALT). Et appuyez sur le bouton "connecter". Vous verrez que le placement de la fenêtre est tout faux. À ce stade, le moyen le plus simple de corriger le bogue est de fermer Mudlet, d'enregistrer le profil, puis de relancer mudlet. Si vous vous connectez au même personnage, le bogue disparaîtra.

Pour reproduire le bogue, tout ce que vous avez à faire est de fermer mudlet et de saisir à nouveau un nom de personnage différent, et de revenir au mauvais placement de la fenêtre, de le redémarrer et de le corriger.

Je pense que j'ai bien décrit comment reproduire ce bogue, mais si quelqu'un a du mal à suivre ce que je dis, je serais heureux de faire une vidéo qui me montre reproduire ce bogue. Faites le moi savoir.

Le code qui enregistre la disposition des fenêtres (ancré: mapper / user windows / toolbars) pourrait-il simplement être borked?

J'ai toujours été un peu difficile de savoir comment il était possible de sauvegarder les données de mise en page alors qu'il pouvait y avoir plusieurs profils chargés (chacun peut-être avec un widget de mappage ancré, avec leurs propres barres d'outils et avec d'autres fenêtres utilisateur ancrées), puis attendez-vous à quand un de ces profils est rechargé pour les données de tous ceux à interpréter, puis également respectés lorsqu'un deuxième ou plusieurs autres profils sont chargés ...

... bien sûr, une ou toutes ces sous- fenêtres peuvent être fusionnées (?) dans une fenêtre ancrée à onglets (effectivement ancrées les unes sur les autres) et que fait la disposition / le code de positionnement de CELA?

@TheFae le

J'ajouterai simplement à cela que cela ne m'arrive que sur Windows, et peut être facilement reproduit sur Windows. Je n'ai jamais vu cela se produire une seule fois sur Linux, je ne sais pas pourquoi Linux est satisfait de la façon dont le profil est mais Windows ne l'est pas. Dès que je pourrai avoir du temps libre, je ferai de mon mieux pour comprendre celui-ci, mon idée était de comparer les données de profil entre une session où le bogue se produit et une session où il ne se produit pas et de rechercher les écarts. Je n'ai tout simplement pas eu assez de temps pour vraiment creuser dans celui-ci.

J'ai comparé les paramètres enregistrés du profil et rien ne semble différent entre avant et après le chargement de mudlet lorsque l'erreur se produit, je me demande quels autres fichiers pourraient être responsables tels que windowLayout.dat (s'il s'agissait d'un fichier xml, la comparaison serait facile, lol )

cependant ce fichier est encodé et je ne suis donc pas sûr de savoir comment le comparer avant / après @ vadi2 savez-vous comment je peux afficher le contenu de ce fichier avant / après un chargement lorsque l'erreur se produit. J'aimerais vraiment traquer et corriger ce bug.

@itsTheFae le

@xekon, ce fichier a été ajouté dans Mudlet 3.2 lorsque userwindows a commencé à se souvenir de sa position: https://www.mudlet.org/2017/06/mudlet-3-2

Vous voulez tester si ce problème existe dans Mudlet 3.1 et 3.2?

Dans la version 3.1, mon profil ne se charge pas de la même manière que je suis également habitué, je suppose que le placement des fenêtres était alors géré différemment.

Cependant, sur la base du premier message de ce rapport, ils ont mentionné que 3.10.1 n'avait pas le problème. J'ai pu reproduire le bogue à 100% à chaque fois et je peux confirmer qu'il n'existait pas est 3.10.1

J'ai continué à tester à la hausse à partir de: 3.11, 3.11.1, 3.12, et enfin 3.13 m'a montré le bogue.

donc pour tester plus loin, j'ai décidé d'essayer de déclasser dans l'ordre commençant par 3.12! et le bogue est présent, même si lors de la mise à niveau incrémentielle de 3.11 à 3.12, cela ne s'est pas produit.

j'ai donc rétrogradé au bug 3.11.1 toujours là.

suivant 3.11, bug toujours là.

suivant 3.10.1 et enfin le bogue résolu.

pour résumer 3.10.1 ne semble pas du tout avoir le bogue.

Après cela, vous pouvez passer de 3.10.1 à 3.11, 3.11.1 ou 3.12 sans rencontrer le bogue, mais dès que vous passez à la version 3.13, vous rencontrerez le bogue.

Après avoir rencontré le bogue avec la version 3.13 ou une version ultérieure, le seul moyen de supprimer complètement le bogue est de passer à la version 3.10.1 (3.11, 3.11.1 ou 3.12 ne résoudra pas le bogue jusqu'à ce que vous rétrogradiez la version 3.10. 1)

Mon instinct est que quelque chose dans le fichier windowLayout.dat n'est pas enregistré correctement. (et d'une manière ou d'une autre, cela n'affecte pas Linux, mais cela affecte Windows.)

Pouvez-vous essayer d'effacer windowLayout.dat entre les mises à niveau 3.10.1 - 3.13?

Si j'efface le fichier windowLayout.dat Le bogue se présente immédiatement, avec 3.11-3.13.

Semble que 3.10.1 était la dernière version à ne pas afficher le bogue.

Donc, la version 3.11 est la version douteuse. https://www.mudlet.org/2018/07/mudlet-3-11-quality-improvements-all-around y a-t-il des notes de version pour cela et https://github.com/Mudlet/Mudlet/compare/Mudlet- 3.10.1 ... Mudlet-3.11.0 est le diff (malheureusement beaucoup de bruit lorsque nous avons supprimé 3rdparty/zziplib )

100% sûr que cela fonctionne bien avec Mudlet-3.10.0? C'est à ce moment que nous sommes passés de Qt 5.6 à 5.11 (que nous utilisons encore à ce jour). Cela aurait pu être un coupable là-dedans et pas dans le code Mudlets. C'est ce que je soupçonnais à l'origine dans https://github.com/Mudlet/Mudlet/issues/2076#issuecomment -432114672

Oui 3.10.1 n'a aucun problème.

Je serais d'accord sur le fait que ce soit Qt sauf que le bogue ne se produit qu'à tous les autres lancements lors du changement du nom du personnage utilisé pour accéder à un profil, ce qui suggère qu'il a quelque chose à voir avec la façon dont les choses sont enregistrées ... C'est pourquoi j'ai voulu creuser dans le valeurs stockées dans windowLayout.dat

Il se peut aussi que la nouvelle version de Qt enregistre / charge les valeurs différemment de celle de l'ancienne version de Qt, mais dans les deux cas, j'ai besoin d'un point de départ pour creuser et voir ce qui se passe. Je dois être en mesure de vérifier les valeurs utilisées par rapport aux valeurs stockées et de déterminer la cause première.

Je vais devoir essayer de rechercher dans le code toutes les occurrences de windowLayout.dat et voir si je peux trouver le meilleur moyen de déboguer ceci :) (je pense un peu quand il enregistre les valeurs dans ce fichier, faites-le également stocker le valeurs à un fichier plat .txt ou xml, afin que je puisse y entrer et regarder)

Ouais. Peut-être que jouer avec https://wiki.mudlet.org/w/Manual : Miscellaneous_Functions # saveWindowLayout et https://wiki.mudlet.org/w/Manual : Miscellaneous_Functions # loadWindowLayout donnera également des résultats.

Grâce à Caled on discord, j'ai découvert que ce bug était probablement lié: https://github.com/Mudlet/Mudlet/issues/2023

Caled a également déclaré: "En outre, ma solution de contournement a été de créer le mappeur et de l'ajouter à GUIframe lors de l'événement 'sysLoadEvent'. Juste au cas où ces informations seraient également utiles"

Cet exemple utilise Jor'Mox GUIFrame et lorsque le mappeur est activé, le bogue est présent:
bugged.zip

voici un exemple sans bogue qui a un mappeur:
bugfree.zip

voici un gif montrant le bogue en action après l'importation du script bogué (vous verrez au lancement ultérieur de ce profil je désactive le chargement de la carte, ce qui semble empêcher le bogue.):

voici un gif montrant le bon fonctionnement du script sans bogue qui a même un mappeur présent:

Avec l'aide de basooza II, cela fonctionne pour que le bogue ne se produise pas. Il semble que le bogue survienne à la suite du déplacement / de l'interaction avec la carte avant le chargement complet de Mudlet, et évidemment seulement dans certaines conditions car j'ai un exemple sans bogue ci-dessus.

La façon dont GUIFrame dessine tous les éléments de l'interface utilisateur rend le bogue de la carte très évident, mais si vous retardez l'interaction avec la carte jusqu'à ce que mudlet soit complètement chargé, cela ne se produira pas.

ÉGALEMENT! ce bogue ne se produit que sur Windows, ce qui signifie que Linux est assez intelligent ou se charge naturellement plus rapidement, donc interagir avec la carte n'est pas un problème. Cependant, sous Windows, vous devez retarder l'interaction ou le déplacement de la carte pendant environ 100 ms pour éviter le bogue.

voici la solution que j'ai trouvée grâce à @basooza :
bugfix_final.zip

Une autre chose que vous remarquerez dans la capture d'écran ci-dessous, j'imprime () le résultat de getMainWindowSize () et vous pouvez voir que le bogue se produit toujours, mais que l'utilisation d'un tempTimer d'au moins 100 ms fonctionne autour de lui:

Aussi pour ajouter à cela ..... simplement avoir un tempTimer ne suffit pas, car j'ai essayé un temps de 0,01 et ce n'était pas assez (10ms) mais 0,1 suffit (100ms)

@ vadi2 a demandé un script TRÈS simple pour reproduire le bogue, le voici:
bug-getMainWindowSize.zip

et une capture d'écran montrant le débogage 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)

Travailler à travers ce problème. Il semblerait que les barres d'outils gauche / droite, où les boutons faciles vont généralement gagner en largeur pendant un moment - et c'est pourquoi il est réduit ici.

@basooza @xekon, veuillez tester si https://github.com/Mudlet/Mudlet/pull/2945 résout le problème que vous décrivez ici. Merci!