Mudlet: Fehler bei der Platzierung des Geysirfensters

Ich denke, das Problem könnte bei getMainWindowSize() das mit einem Qt-Upgrade kaputt gegangen ist, was die Symptome erklären würde, dass wir den Geysir-Kern seit Ewigkeiten nicht mehr berührt haben, aber kürzlich kaputt gegangen sind (Änderung der Qt-Version). Sehen Sie, ob diese Funktion der Schuldige für Sie ist.

So wird es berechnet: https://github.com/Mudlet/Mudlet/blob/development/src/TConsole.cpp#L2776

: +1: Ich bin mir nicht sicher, ob ich derzeit mit meinem RL zu dieser Diskussion beitragen kann, aber ich kann mich bei @basooza für einen meiner Meinung nach konstruktiven

Ich wollte hier nach dem Testen nur einige Informationen hinzufügen. Wenn ich Mudlet zum ersten Mal unter Windows 8.1 starte und meine Windows-Platzierung falsch ist. Ich kann lua display (getMainWindowSize ()) ausführen und es zeigt tatsächlich falsche Werte an. Um dies zu beheben, maximiere ich das Fenster und ziehe dann die untere rechte Ecke, um die Größe des Fensters zu ändern. Dann setze ich es wieder auf Maximiert.

Ich habe auch festgestellt, dass Sie die Sichtbarkeit der Hauptsymbolleiste umschalten können, und das wird es auch beheben! Es scheint also, dass alles, was die MainWindowSize betrifft, ausreicht, um dieses Problem zu beheben. Ich frage mich, ob wir als Problemumgehung die Sichtbarkeit der Hauptsymbolleiste oder etwas anderes schnell ausblenden / anzeigen könnten. Das würde es wahrscheinlich beheben, bis das Problem mit QT behoben ist.

Probieren Sie es aus!

Ich habe weitere Informationen zu liefern. anstatt die Größe des Fensters zu ändern. Sie können einfach auf die Schaltfläche "Schließen" für "Mudlet" in der oberen rechten Ecke klicken und mit "Ja" antworten, um das Profil zu speichern. Beim nächsten Start wird diese seltsame Platzierung nicht stattfinden.

Im Grunde ist es also jeder zweite Start, bei dem Sie dieses Problem sehen. Ich werde mich mit dieser neuen Entdeckung auf die Probe stellen und sagen, dass möglicherweise nicht QT dafür verantwortlich ist, andernfalls, warum es nicht bei jedem zweiten Start repariert / korrekt ist. Ich vermute, es hat mit etwas zu tun, das im Profil gespeichert ist. Vielleicht würde ein Vergleich der Profildaten aus beiden Zuständen etwas Licht ins Dunkel bringen.

Ich werde sehen, ob ich das noch weiter debuggen kann ...

Nun, ich habe mich noch nicht mit dem Prozess befasst, herauszufinden, warum dies geschieht, aber mit der fortgesetzten Verwendung von Mudlet habe ich herausgefunden, wie ich es jedes Mal reproduzieren kann. Erstens scheint es mehrere Dinge zu geben, die diesen Fehler auslösen können. Sie scheinen alle mit Problemen beim ordnungsgemäßen Laden / Speichern des Profils verbunden zu sein. Dieses besondere ist genau so, wie ich es jedes Mal reproduziert habe.

Deaktivieren Sie auf einem Windows-System zunächst die Einstellung im Menü Spiele-> Spielen "Profil beim Start von Mudlet öffnen". Um zum Menü Spiele -> Spielen zu gelangen, deaktivieren Sie das Kontrollkästchen und klicken Sie auf Verbinden. Sobald das Profil geöffnet ist, können Sie Mudlet schließen, das Profil speichern und Mudlet erneut starten.

An diesem Punkt sollte das Mudlet so konfiguriert werden, dass es nicht automatisch ein Profil startet.

Hier ist der nächste Teil: Wenn Sie Mudlet starten und dann im Feld "Charaktername" einen anderen Charakternamen eingeben (z. B. ein ALT-Zeichen). Und klicken Sie auf die Schaltfläche "Verbinden". Sie werden sehen, dass die Fensterplatzierung falsch ist. Zu diesem Zeitpunkt können Sie den Fehler am einfachsten beheben, indem Sie Mudlet schließen, das Profil speichern und dann Mudlet neu starten. Wenn Sie sich bei demselben Charakter anmelden, ist der Fehler behoben.

Um den Fehler zu reproduzieren, müssen Sie nur das Mudlet schließen und erneut einen anderen Charakternamen eingeben.

Ich denke, ich habe gut beschrieben, wie man diesen Fehler reproduziert, aber wenn jemand Probleme hat, dem zu folgen, was ich sage, würde ich gerne ein Video machen, das mir zeigt, wie ich diesen Fehler reproduziere. Lass es mich wissen.

Könnte der Code, der das Windows-Layout (angedockt: Mapper / Benutzerfenster / Symbolleisten) speichert, nur verzerrt werden?

Ich war mir immer ein bisschen unklar, wie es möglich sein könnte, die Layoutdaten zu speichern, wenn mehrere Profile geladen werden könnten (jedes möglicherweise mit einem angedockten Mapper-Widget, mit eigenen Symbolleisten und mit anderen angedockten Benutzerfenstern) und dann zu erwarten, wann eines Von diesen Profilen werden die Daten für alle zu interpretierenden Profile neu geladen und dann auch berücksichtigt, wenn ein zweites oder mehrere andere Profile geladen werden ...

... natürlich können alle oder alle diese Unterfenster zusammengeführt (?) in ein mit Registerkarten angedocktes Fenster (effektiv übereinander angedockt) werden. Und was macht dann der Layout- / Positionscode aus DIESEM?

@ TheFae würdest du wissen?

Ich werde nur hinzufügen, dass es mir nur unter Windows passiert und leicht unter Windows reproduziert werden kann. Ich habe noch nie gesehen, dass dies unter Linux passiert. Ich bin mir nicht sicher, warum Linux mit dem Profil zufrieden ist, Windows jedoch nicht. Sobald ich etwas Freizeit habe, werde ich mein Bestes geben, um dies herauszufinden. Meine Idee war es, die Profildaten zwischen einer Sitzung, in der der Fehler auftritt, und einer Sitzung, in der er nicht auftritt, zu vergleichen und nach Unstimmigkeiten zu suchen. Ich hatte einfach noch nicht genug Zeit, um mich wirklich mit diesem zu beschäftigen.

Ich habe die Einstellungen für das Profil gespeichert und nichts sieht zwischen vor und nach dem Laden von Mudlet anders aus, wenn der Fehler auftritt. Ich frage mich, welche anderen Dateien wie windowLayout.dat dafür verantwortlich sein könnten (wenn dies eine XML-Datei wäre, wäre ein Vergleich einfach, lol )

Diese Datei ist jedoch verschlüsselt und ich bin mir nicht sicher, wie ich sie vor / nach Wissen Sie, wie ich den Inhalt dieser Datei vor / nach dem Laden ? Ich würde diesen Fehler wirklich gerne aufspüren und beheben.

@itsTheFae würdest du wissen?

@xekon Diese Datei wurde in Mudlet 3.2 hinzugefügt, als sich Benutzerfenster an ihre Position erinnerten: https://www.mudlet.org/2017/06/mudlet-3-2

Möchten Sie testen, ob dieses Problem in Mudlet 3.1 und 3.2 vorliegt?

In 3.1 wird mein Profil nicht auf eine Weise geladen, die ich auch verwende. Ich nehme an, dass die Fensterplatzierung anders gehandhabt wurde.

Basierend auf dem ersten Beitrag dieses Berichts hatten sie jedoch 3.10.1 nicht das Problem. Ich konnte den Fehler jedes Mal zu 100% reproduzieren und kann bestätigen, dass er nicht vorhanden ist (3.10.1)

Ich testete weiter nach oben von: 3.11, 3.11.1, 3.12 und schließlich zeigte mir 3.13 den Fehler.

Um weiter zu testen, habe ich mich entschlossen, ein Downgrade durchzuführen, um mit 3.12 zu beginnen! und der Fehler ist vorhanden, obwohl es nicht passiert ist, als ich schrittweise von 3.11 auf 3.12 aktualisiert habe.

Also habe ich noch ein Downgrade auf 3.11.1 durchgeführt.

nächste 3.11, Fehler noch da.

weiter 3.10.1 und schließlich der Fehler behoben.

3.10.1 zusammenzufassen scheint den Fehler überhaupt nicht zu haben.

Danach können Sie ein Upgrade von 3.10.1 auf 3.11, 3.11.1 oder 3.12 durchführen, ohne dass der Fehler auftritt. Sobald Sie jedoch ein Upgrade auf 3.13 durchführen, tritt der Fehler auf.

Nachdem der Fehler mit 3.13 oder höher aufgetreten ist, besteht die einzige Möglichkeit, den Fehler vollständig zu beheben, darin, auf 3.10.1 herunterzustufen (3.11, 3.11.1 oder 3.12 beheben den Fehler erst, wenn Sie das erste Downgrade auf 3.10 durchführen. 1)

Mein Bauchgefühl ist, dass etwas in der Datei windowLayout.dat nicht ordnungsgemäß gespeichert wird. (und irgendwie wirkt sich das nicht auf Linux aus, aber auf Windows.)

Können Sie versuchen, windowLayout.dat zwischen den Upgrades 3.10.1 - 3.13 zu löschen?

Wenn ich die Datei windowLayout.dat lösche Der Fehler tritt sofort mit 3.11-3.13 auf.

3.10.1 war anscheinend die letzte Version, in der der Fehler nicht angezeigt wurde.

3.11 ist also die zwielichtige Veröffentlichung. https://www.mudlet.org/2018/07/mudlet-3-11-quality-improvements-all-around gibt es Versionshinweise dafür und https://github.com/Mudlet/Mudlet/compare/Mudlet- 3.10.1 ... Mudlet-3.11.0 ist der 3rdparty/zziplib )

100% sicher, dass es mit Mudlet-3.10.0 funktioniert? Zu diesem Zeitpunkt haben wir von Qt 5.6 auf 5.11 gewechselt (das wir bis heute verwenden). Könnte dort ein Schuldiger gewesen sein und nicht im Mudlets-Code. Es ist das, was ich ursprünglich in https://github.com/Mudlet/Mudlet/issues/2076#issuecomment -432114672 vermutet habe

Ja, 3.10.1 hat keine Probleme.

Ich würde zustimmen, dass es Qt ist, außer dass der Fehler nur bei jedem zweiten Start auftritt, wenn der Charaktername geändert wird, der für den Zugriff auf ein Profil verwendet wird, was darauf hindeutet, dass es etwas damit zu tun hat, wie Dinge gespeichert werden ... Deshalb wollte ich mich mit dem befassen in der windowLayout.dat gespeicherte Werte

Es könnte auch sein, dass die neuere Version von Qt Werte anders speichert / lädt als die ältere Version von Qt, aber in beiden Fällen brauche ich einen Ausgangspunkt, um zu sehen, was los ist. Ich muss in der Lage sein, die verwendeten Werte mit den gespeicherten Werten zu vergleichen und herauszufinden, was die Grundursache ist.

Ich muss versuchen, im Code nach allen Vorkommen von windowLayout.dat zu suchen und zu sehen, ob ich den besten Weg zum Debuggen finden kann :) (Ich denke, wenn es Werte in dieser Datei speichert, muss er auch die speichern Werte in eine flache TXT- oder XML-Datei, damit ich dort hineinkommen und nachsehen kann)

Ja. Vielleicht führt das Herumspielen mit https://wiki.mudlet.org/w/Manual : Miscellaneous_Functions # saveWindowLayout und https://wiki.mudlet.org/w/Manual : Miscellaneous_Functions # loadWindowLayout auch zu einigen Ergebnissen.

Dank Caled on Discord habe ich herausgefunden, dass dieser Fehler wahrscheinlich damit zusammenhängt: https://github.com/Mudlet/Mudlet/issues/2023

Caled sagte auch: "Meine Problemumgehung bestand darin, den Mapper zu erstellen und beim 'sysLoadEvent'-Ereignis zu GUIframe hinzuzufügen. Nur für den Fall, dass diese Informationen auch nützlich sind."

In diesem Beispiel wird Jor'Mox GUIFrame verwendet. Wenn der Mapper aktiviert ist, ist der Fehler vorhanden:
bugged.zip

Hier ist ein fehlerfreies Beispiel mit einem Mapper:
bugfree.zip

Hier ist ein GIF, das den Fehler in Aktion nach dem Importieren des fehlerhaften Skripts zeigt (Sie werden beim späteren Start dieses Profils sehen, dass ich das Laden der Karte deaktiviere, was den Fehler zu verhindern scheint.):

Hier ist ein GIF, das die ordnungsgemäße Funktion des fehlerfreien Skripts zeigt, in dem sogar ein Mapper vorhanden ist:

Mit basooza help II hat dies funktioniert, damit der Fehler nicht auftritt. Es scheint, dass der Fehler durch das Verschieben / Interagieren mit der Karte vor dem vollständigen Laden von Mudlet auftritt, und natürlich nur unter bestimmten Bedingungen, da ich oben ein fehlerfreies Beispiel habe.

Die Art und Weise, wie GUIFrame alle Ui-Elemente zeichnet, macht den Kartenfehler sehr offensichtlich. Wenn Sie jedoch die Interaktion mit der Karte verzögern, bis das Mudlet vollständig geladen ist, geschieht dies nicht.

EBENFALLS! Dieser Fehler tritt nur unter Windows auf, was bedeutet, dass Linux intelligent genug ist oder natürlich schneller geladen wird, sodass die Interaktion mit der Karte kein Problem darstellt. Unter Windows müssen Sie jedoch die Interaktion mit oder das Verschieben der Karte um ca. 100 ms verzögern, um den Fehler zu vermeiden.

Hier die Lösung, die ich dank @basooza gefunden habe :
bugfix_final.zip

Eine andere Sache, die Sie im folgenden Screenshot bemerken werden: Ich drucke () das Ergebnis von getMainWindowSize () und Sie können sehen, dass der Fehler immer noch auftritt, aber dass die Verwendung eines TempTimers von mindestens 100 ms dies umgeht:

Außerdem ist es nicht genug, nur einen tempTimer zu haben, da ich eine Zeit von 0,01 ausprobiert habe und das nicht genug war (10 ms), aber 0,1 ist genug (100 ms).

@ vadi2 hat ein SEHR einfaches Skript angefordert, um den Fehler zu reproduzieren. Hier ist es:
bug-getMainWindowSize.zip

und ein Screenshot mit dem print () - Debug:

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)

Dieses Problem durcharbeiten. Es scheint, als würden die linken / rechten Symbolleisten, in denen sich die einfachen Schaltflächen befinden, normalerweise für einen Moment an Breite gewinnen - und deshalb wird sie hier reduziert.

@basooza @xekon Bitte testen Sie, ob https://github.com/Mudlet/Mudlet/pull/2945 das hier beschriebene Problem behebt. Danke!