Mudlet: 間欠泉ウィンドウ配置のバグ

問題は、Qtアップグレードで壊れたgetMainWindowSize()あると思います。これは、私たちが何年もの間間欠泉コアに触れていなかったが、最近壊れた（Qtバージョンの変更）という症状を説明します。 その機能があなたの犯人であるかどうかを確認してください。

計算方法は次のとおりです： https ：

：+1：現時点では、RLをそのまま使用してこのディスカッションに貢献できるかどうかはわかりませんが、建設的な問題レポートだと思う

テスト後にここに情報を追加したかっただけです。 Windows 8.1でMudletを最初に起動したとき、Windowsの配置が正しくありません。 lua display（getMainWindowSize（））を実行できますが、実際に誤った値が表示されます。 これを修正するには、ウィンドウの最大化を解除し、右下隅をドラッグしてウィンドウのサイズを変更してから、最大化に戻します。

また、メインツールバーの表示を切り替えることができ、それによって修正されることもわかりました。 したがって、MainWindowSizeに影響を与えるものであれば、この問題を修正するのに十分なようです。 回避策として、メインツールバーの可視性などをすばやく非表示/表示できるかどうか疑問に思っています。 QTの問題が解決されるまで、それで修正される可能性があります。

試してごらん！

提供する情報がもっとあります。 ウィンドウのサイズを変更する代わりに。 右上隅にあるMudletの閉じるボタンを押すだけで、[はい]と答えてプロファイルを保存できます。 次の起動では、この奇妙な配置は発生しません。

つまり、基本的に、この問題が発生するのは1つおきの起動です。 私はこの新しい発見に気を配り、責任があるのはQTではないかもしれないと言います。そうでなければ、他のすべての起動で修正/修正されないのはなぜですか。 私の推測では、それはプロファイルに保存されているものと関係があり、おそらく両方の状態からのプロファイルデータを比較することはいくつかの光を当てるでしょう。

これをさらにデバッグできるかどうかを確認します。

さて、なぜこれが起こるのかを理解するプロセスをまだ掘り下げていませんが、マドレットを使い続けることで、毎回それを再現する方法を理解しました。 まず、このバグを引き起こす可能性のあるものは複数あるようです。それらはすべて、プロファイルの適切な読み込み/保存に関する問題に関連しているようです。 この特定のものは、私が毎回それを再現することを見つけた方法です。

Windowsシステムでは、最初にゲーム-> [プレイ]メニューの[マッドレットの開始時にプロファイルを開く]の設定をオフにします。 メニューの[ゲーム]-> [再生]に移動するには、チェックボックスをオフにして[接続]をクリックします。 プロファイルが開いたら、マドレットを閉じてプロファイルを保存し、マドレットを再度起動できます。

その時点で、マドレットはプロファイルを自動的に起動しないように構成する必要があります。

次のパートは次のとおりです。Mudletを起動してから[キャラクター名]フィールドに別のキャラクター名（ALTキャラクターなど）を入力します。 そして、「接続」ボタンを押します。 ウィンドウの配置がすべて間違っていることがわかります。 この時点で、バグを修正する最も簡単な方法は、マドレットを閉じてプロファイルを保存してから、マドレットを再起動することです。 同じキャラクターにログインすると、バグはなくなります。

バグを再現するには、マッドレットを閉じて別のキャラクター名をもう一度入力し、不適切なウィンドウの配置に戻って再起動し、修正するだけです。

私はこのバグを再現する方法をうまく説明できたと思いますが、誰かが私が言っていることを理解するのに問題がある場合は、このバグを再現することを示すビデオを作成したいと思います。 私に知らせて。

（ドッキング：マッパー/ユーザーウィンドウ/ツールバー）ウィンドウレイアウトを保存するコードは、単に中断される可能性がありますか？

私はいつも、複数のプロファイルが当時と（自分のツールバーで、その他のドッキングユーザウィンドウを持つ可能性がドッキングされたマッパーウィジェットとのそれぞれが、）とき1を期待ロードがあるかもしれないときには、レイアウトデータを保存することは可能かもしれないどのようビット不明確てきましたそれらのプロファイルのうち、解釈されるすべてのデータのために再ロードされ、2番目以上の他のプロファイルがロードされたときにも尊重されます...

...もちろん、これらのサブウィンドウのいずれか、またはすべてを、タブ付きのドッキングウィンドウ（効果的に相互にドッキング）にマージドッキング（？）すること

@TheFaeあなたは知っていますか？

これに加えて、これはWindowsでのみ発生し、Windowsで簡単に再現できることを付け加えておきます。 私はこれがLinuxで起こるのを見たことがありません。なぜ、Linuxはプロファイルの状態に満足しているのに、Windowsはそうではないのかわかりません。 暇ができたらすぐにこれを理解するために最善を尽くします。私の考えは、バグが発生したセッションと発生していないセッションのプロファイルデータを比較し、不一致を探すことでした。 私はまだこれを実際に掘り下げるのに十分な時間がありませんでした。

プロファイルに保存された設定を比較しましたが、エラーが発生したときにマッドレットのロードの前後で何も変わらないように見えますが、windowLayout.datなどの他のファイルが原因である可能性があります（これがxmlファイルの場合、比較は簡単です、笑）

ただし、そのファイルはエンコードされているため、 @ vadi2の前後で比較する方法が

@itsTheFaeあなたは知っていますか？

@xekonそのファイルはuserwindowsが自分の位置を記憶し始めたときにMudlet3.2で追加されました： https ：//www.mudlet.org/2017/06/mudlet-3-2

この問題がMudlet3.1および3.2に存在するかどうかをテストしたいですか？

3.1では、私のプロファイルは私も使用している方法で読み込まれません。ウィンドウの配置はそのときとは異なる方法で処理されたと思います。

ただし、このレポートの最初の投稿に基づいて、3.10.1には問題がないと述べました。 毎回100％再現できており、存在しなかったのは3.10.1です。

3.11、3.11.1、3.12から上向きにテストを続け、最後に3.13でバグが表示されました。

それで、さらにテストするために、3.12から順番にダウングレードしてみることにしました！ 3.11から3.12に段階的にアップグレードしても、バグは発生しませんでした。

そのため、まだそこにある3.11.1バグにさらにダウングレードしました。

次の3.11、バグはまだあります。

次の3.10.1そして最後にバグは解決しました。

要約すると、3.10.1にはバグがまったくないようです。

その後、バグを経験せずに3.10.1から3.11、3.11.1、または3.12にアップグレードできますが、3.13にアップグレードするとすぐにバグが発生します。

3.13以降でバグを経験した後、バグを完全にクリアする唯一の方法は、3.10.1にダウングレードすることです（3.11、3.11.1、または3.12は、最初に3.10までダウングレードするまでバグをクリアしません。 1）

私の直感は、windowLayout.datファイル内の何かが不適切に保存されているということです。 （そしてどういうわけかこれはLinuxには影響しませんが、Windowsには影響します。）

アップグレード3.10.1〜3.13の間にwindowLayout.datをクリアしてみてください。

windowLayout.datファイルをクリアすると、3.11〜3.13でバグがすぐに発生します。

3.10.1はバグを表示しなかった最後のバージョンだったようです。

したがって、3.11は危険なリリースです。 https://www.mudlet.org/2018/07/mudlet-3-11-quality-improvements-all-aroundリリースノートとます3.10.1 ... Mudlet-3.11.0は差分です（残念ながら、未使用の3rdparty/zziplibを削除すると多くのノイズが発生します）

Mudlet-3.10.0で問題なく動作することを100％確信していますか？ そのとき、Qt 5.6から5.11に変更しました（現在でも使用しています）。 マドレットコードではなく、そこに原因があった可能性があります。 それは私がhttps://github.com/Mudlet/Mudlet/issues/2076#issuecomment-432114672で最初に疑ったものです

はい3.10.1には問題はありません。

バグは、プロファイルへのアクセスに使用されるキャラクター名を変更したときに1回おきに発生することを除いて、Qtであることに同意します。これは、保存方法と関係があることを示唆しています...そのため、 windowLayout.datに格納されている値

新しいバージョンのQtは、古いバージョンのQtとは異なる方法で値を保存/ロードしている可能性もありますが、どちらの場合も、掘り下げて何が起こっているかを確認するための開始点が必要です。 使用されている値と保存されている値を確認し、根本的な原因を特定できる必要があります。

windowLayout.datのすべての出現についてコードを調べて、これをデバッグするための最良の方法を見つけられるかどうかを確認する必要があります：）（値をそのファイルに保存するときに、値を保存するように考えています。フラットな.txtまたはxmlファイルに値を設定して、そこにアクセスして確認できるようにします）

うん。 たぶんで遊んhttps://wiki.mudlet.org/w/Manual ：Miscellaneous_Functions＃saveWindowLayoutとhttps://wiki.mudlet.org/w/Manual ：Miscellaneous_Functions＃loadWindowLayoutあまりにもいくつかの結果が得られます。

Caled on discordのおかげで、このバグが関連している可能性が高いことがわかりました： https ：

Caledはまた、次のように述べています。「また、私の回避策は、マッパーを作成し、「sysLoadEvent」イベントでGUIframeに追加することでした。その情報も役立つ場合に備えて」

この例ではJor'MoxGUIFrameを使用しており、マッパーを有効にするとバグが発生します。
bugged.zip

マッパーを備えたバグのない例を次に示します。
bugfree.zip

これは、バグのあるスクリプトをインポートした後のバグの動作を示すgifです（このプロファイルを後で起動すると、マップの読み込みが無効になり、バグが防止されるようです）。

これは、マッパーが存在するバグのないスクリプトの適切な機能を示すgifです。

basooza help IIを使用すると、バグが発生しないようにこれが機能します。 バグは、Mudletが完全に読み込まれる前にマップを移動/操作した結果として発生しているようです。上記のバグのない例があるため、明らかに特定の条件下でのみ発生します。

GUIFrameがすべてのUi要素を描画する方法は、マップのバグを非常に明白にしますが、マッドレットが完全にロードされるまでマップとの対話を遅らせると、それは起こりません。

また！ このバグはWindowsでのみ発生します。つまり、Linuxは十分にスマートであるか、自然に高速に読み込まれるため、マップとの対話は問題になりません。 ただし、Windowsでは、バグを回避するために、マップの操作または移動を約100ミリ秒遅らせる必要があります。

ここで私が@basoozaのおかげで思いついた解決策：
bugfix_final.zip

下のスクリーンショットで、getMainWindowSize（）の結果をprint（）すると、バグがまだ発生していることがわかりますが、少なくとも100msのtempTimerを使用すると回避できます。

また、これに追加するには..... tempTimerを持っているだけでは十分ではありません。0.01の時間を試したので、それでは不十分（10ms）でしたが、0.1で十分（100ms）です。

@ vadi2は、バグを再現するための
バグ-getMainWindowSize.zip

および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)

この問題に取り組んでいます。 簡単なボタンが通常少しの間幅を増す場所である左/右のツールバーのように見えます-そしてそれがここでそれが縮小されている理由です。

@basooza @xekon https://github.com/Mudlet/Mudlet/pull/2945で、ここで説明する問題が修正されるかどうかをテストして