Mudlet: علة وضع نافذة السخان

أعتقد أن المشكلة قد تكون مع getMainWindowSize() الذي تم كسره من خلال ترقية Qt ، مما يفسر لنا أعراض عدم لمسنا لنواة Geyser في الأعمار ولكنه كسر مؤخرًا (تغيير إصدار Qt). معرفة ما إذا كانت هذه الوظيفة هي الجاني بالنسبة لك.

إليك كيفية حسابها: https://github.com/Mudlet/Mudlet/blob/development/src/TConsole.cpp#L2776

: +1: لست متأكدًا من أنه يمكنني المساهمة في هذه المناقشة في الوقت الحاضر مع RL الخاص بي كما هو ، ولكن هل يمكنني فقط أن أشكرك @ basooza على ما أعتقد أنه تقرير مشكلة بناء - أشعر أن هناك هناك الكثير من التفاصيل ذات الصلة التي ستكون مفيدة خاصةً فيما يتعلق بتضييق نطاق الإصدارات التي أظهرت المشكلة أولاً ...

أردت فقط إضافة بعض المعلومات هنا بعد الاختبار. عندما أقوم بتشغيل Mudlet لأول مرة على Windows 8.1 وكان وضع Windows الخاص بي غير صحيح. يمكنني تشغيل lua display (getMainWindowSize ()) ويظهر بالفعل قيمًا غير صحيحة. لإصلاح هذا ، أقوم بإلغاء تكبير النافذة ، ثم اسحب الزاوية اليمنى السفلية لتغيير حجم النافذة ، ثم أعدها إلى الحد الأقصى.

لقد اكتشفت أيضًا أنه يمكنك تبديل رؤية شريط الأدوات الرئيسي ، وسيؤدي ذلك إلى إصلاحه أيضًا! لذلك يبدو أن أي شيء يؤثر على MainWindowSize يكفي لإصلاح هذه المشكلة. أتساءل عما إذا كان بإمكاننا كحل بديل إخفاء / إظهار رؤية شريط الأدوات الرئيسي بسرعة أو شيء من هذا القبيل. من المحتمل أن يؤدي ذلك إلى إصلاحه حتى يتم حل مشكلة QT.

جربها!

لدي المزيد من المعلومات لتقديمها. بدلا من تغيير حجم النافذة. يمكنك فقط الضغط على زر الإغلاق لـ Mudlet في الزاوية اليمنى العليا ، والإجابة بنعم لحفظ الملف الشخصي. لن يحدث هذا التنسيب الغريب في الإطلاق التالي.

لذلك في الأساس ، كل عملية إطلاق أخرى ترى هذه المشكلة. سأخرج على طرف مع هذا الاكتشاف الجديد وأقول إنه قد لا يكون QT هو المسؤول ، وإلا فلماذا لن يتم إصلاحه / يكون صحيحًا في كل عملية إطلاق أخرى. تخميني هو أن الأمر يتعلق بشيء تم حفظه في الملف الشخصي ، وربما تلقي مقارنة بيانات الملف الشخصي من كلتا الحالتين ببعض الضوء.

سأرى ما إذا كان بإمكاني تصحيح هذا أبعد ...

حسنًا ، لم أتعمق بعد في عملية اكتشاف سبب حدوث ذلك ، ولكن مع استمرار استخدام Mudlet ، اكتشفت كيفية إعادة إنتاجه في كل مرة. أولاً ، يبدو أن هناك عدة أشياء يمكن أن تؤدي إلى حدوث هذا الخطأ ، ويبدو أنها جميعًا مرتبطة بمشكلات في ملف التعريف الذي يتم تحميله / حفظه بشكل صحيح. هذا بالذات هو بالضبط كيف وجدت إعادة إنتاجه في كل مرة.

في نظام Windows ، قم أولاً بإعداد الإعدادات من قائمة الألعاب -> قائمة التشغيل "فتح ملف التعريف على بدء تشغيل Mudlet" غير محدد. للوصول إلى قائمة الألعاب -> تشغيل ، قم بإلغاء تحديد المربع واضغط على اتصال. بمجرد فتح ملف التعريف ، يمكنك إغلاق Mudlet ، وحفظ الملف الشخصي ، ثم تشغيل mudlet مرة أخرى.

عند النقطة يجب تكوين mudlet بحيث لا يتم تشغيل ملف تعريف تلقائيًا.

الآن ها هو الجزء التالي ، إذا قمت بتشغيل Mudlet ثم في حقل "اسم الحرف" ، قم بملء اسم حرف مختلف (مثل حرف ALT). واضغط على زر "اتصال". سترى أن وضع النافذة خاطئ تمامًا. في هذه المرحلة ، أسهل طريقة لإصلاح الخطأ هي إغلاق Mudlet ، وحفظ الملف الشخصي ، ثم إعادة تشغيل mudlet. إذا قمت بتسجيل الدخول إلى نفس الشخصية ، فسيختفي الخطأ.

لإعادة إنتاج الخطأ ، كل ما عليك فعله هو إغلاق mudlet وإدخال اسم حرف مختلف مرة أخرى ، وظهرك إلى وضع غير مناسب للنافذة ، وإعادة التشغيل والإصلاح.

أعتقد أنني قمت بعمل جيد لوصف كيفية إعادة إنتاج هذا الخطأ ، ولكن إذا واجه أي شخص مشكلة في متابعة ما أقوله ، فسيسعدني إنشاء مقطع فيديو يوضح لي إعادة إنتاج هذا الخطأ. فقط دعني اعرف.

هل يمكن أن يكون الكود الذي يحفظ تخطيط النوافذ (المرسى: mapper / user windows / toolbars) مجرد borked؟

لقد كنت دائما غير واضح قليلا كيف يمكن أن يكون من الممكن لحفظ البيانات تخطيط عند يمكن أن يكون هناك ملامح متعددة تحميل (كل وربما مع رست مخطط القطعة، مع أشرطة الأدوات الخاصة بهم ومع غيرها من النوافذ المستخدم رست) ونتوقع بعد ذلك عند واحد من هذه الملفات الشخصية يتم إعادة تحميلها للبيانات ليتم تفسيرها جميعًا ثم يتم احترامها أيضًا عند تحميل ملفات تعريف ثانية أو أكثر ...

... بالطبع أي ، أو كل هذه النوافذ الفرعية يمكن دمجها (؟) في نافذة مثبتة بعلامات تبويب (مثبتة بشكل فعال فوق بعضها البعض) ثم ما الذي يصنعه التخطيط / الرمز الوضعي من ذلك؟

@ TheFae هل تعلم؟

سأضيف فقط إلى هذا ، أنه يحدث لي فقط على النوافذ ، ويمكن استنساخه بسهولة على النوافذ. لم أشاهد هذا يحدث على لينكس أبدًا ، لست متأكدًا من سبب رضاء لينكس عن ملف التعريف ولكن النوافذ ليست كذلك. بمجرد أن أحصل على بعض وقت الفراغ ، سأبذل قصارى جهدي لمعرفة ذلك ، كانت فكرتي هي مقارنة بيانات الملف الشخصي بين جلسة يحدث فيها الخطأ وجلسة لا تحدث فيها والبحث عن التناقضات. لم يكن لدي ما يكفي من الوقت للبحث في هذا الأمر حتى الآن.

لقد قارنت الإعدادات المحفوظة لملف التعريف ولا يبدو أي شيء مختلفًا بين قبل وبعد تحميل mudlet عند حدوث الخطأ ، أتساءل ما هي الملفات الأخرى التي قد تكون مسؤولة مثل windowLayout.dat (إذا كان هذا ملفًا بتنسيق xml فسيكون من السهل ، لول )

ومع ذلك ، تم ترميز هذا الملف ولذا فأنا لست متأكدًا من كيفية مقارنته قبل / بعد @ vadi2 ، هل تعرف كيف يمكنني عرض محتويات هذا الملف قبل / بعد التحميل عند حدوث الخطأ. أود حقًا تعقب هذا الخطأ وإصلاحه.

itsTheFae هل تعلم؟

تمت إضافة هذا الملف إلىxekon في Mudlet 3.2 عندما بدأ userwindows في تذكر موقعه: https://www.mudlet.org/2017/06/mudlet-3-2

هل تريد اختبار ما إذا كانت هذه المشكلة موجودة في Mudlet 3.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 ، ولكنه يؤثر على النوافذ.)

هل يمكنك محاولة مسح windowLayout.dat بين الترقيات 3.10.1 - 3.13؟

إذا قمت بمسح ملف windowLayout.dat ، فإن الخطأ يعرض نفسه على الفور ، مع 3.11-3.13.

يبدو أن الإصدار 3.10.1 كان الإصدار الأخير الذي لم يعرض الخطأ.

إذن 3.11 هو الإصدار المراوغ. https://www.mudlet.org/2018/07/mudlet-3-11-quality-improvements-all-around هل توجد ملاحظات إصدار لها و https://github.com/Mudlet/Mudlet/compare/Mudlet- 3.10.1 ... Mudlet-3.11.0 هو الفرق (للأسف الكثير من الضوضاء عندما أزلنا غير مستخدم 3rdparty/zziplib )

100٪ متأكد من أنه يعمل بشكل جيد مع Mudlet-3.10.0؟ هذا عندما تغيرنا من Qt 5.6 إلى 5.11 (الذي ما زلنا نستخدمه حتى يومنا هذا). يمكن أن يكون الجاني هناك وليس في كود Mudlets. هذا ما كنت أشتبه به في الأصل في https://github.com/Mudlet/Mudlet/issues/2076#issuecomment -432114672

نعم 3.10.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://github.com/Mudlet/Mudlet/issues/2023

قال كاليد أيضًا: "كان الحل البديل هو إنشاء مخطط وإضافة إلى GUIframe في حدث 'sysLoadEvent'. فقط في حالة فائدة هذه المعلومات أيضًا"

يستخدم هذا المثال إطار Jor'Mox GUIFrame وعندما يتم تمكين مصمم الخرائط ، يكون الخطأ موجودًا:
bugged.zip

إليك مثال خالٍ من الأخطاء يحتوي على مصمم خرائط:
bugfree.zip

إليك صورة gif تظهر الخطأ أثناء العمل بعد استيراد البرنامج النصي الذي تم التنصت عليه (سترى عند الإطلاق اللاحق لهذا الملف الشخصي ، أقوم بتعطيل تحميل الخريطة ، والذي يبدو أنه يمنع الخطأ.):

إليك صورة gif تظهر الوظيفة المناسبة للنص البرمجي bugfree الذي يحتوي حتى على مخطط:

بمساعدة basooza حصلت II على هذا العمل حتى لا يحدث الخطأ. يبدو أن الخطأ يحدث نتيجة للتحرك / التفاعل مع الخريطة قبل تحميل Mudlet بالكامل ، ومن الواضح أنه فقط في ظل ظروف معينة لأن لدي مثالًا خالٍ من الأخطاء أعلاه.

الطريقة التي يرسم بها GUIFrame جميع عناصر واجهة المستخدم تجعل خطأ الخريطة واضحًا جدًا ، ولكن إذا قمت بتأخير التفاعل مع الخريطة حتى يتم تحميل mudlet بالكامل ، فلن يحدث ذلك.

أيضا! يحدث هذا الخطأ فقط على نظام Windows ، مما يعني أن Linux ذكي بدرجة كافية أو يتم تحميله بشكل أسرع بشكل طبيعي ، لذا فإن التفاعل مع الخريطة ليس مشكلة. ومع ذلك ، في النوافذ ، تحتاج إلى تأخير التفاعل مع الخريطة أو تحريكها لحوالي 100 مللي ثانية لتجنب الخطأ.

هنا الحل الذي توصلت إليه بفضل basooza :
bugfix_final.zip

شيء آخر ستلاحظه في لقطة الشاشة أدناه أقوم بطباعة () نتيجة getMainWindowSize () ويمكنك أن ترى أن الخطأ لا يزال يحدث ، ولكن استخدام مؤقت زمني على الأقل 100 مللي ثانية يعمل حوله:

أيضًا للإضافة إلى هذا ..... ببساطة لا يكفي وجود مؤقت مؤقت ، لأنني جربت وقتًا قدره 0.01 ولم يكن ذلك كافيًا (10 مللي ثانية) ولكن 0.1 كافي (100 مللي ثانية)

طلب @ vadi2 برنامج نصي بسيط للغاية لإعادة إنتاج الخطأ ، وهنا هو:
bug-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)

العمل من خلال هذه القضية. يبدو أن أشرطة الأدوات اليسرى / اليمنى هي المكان الذي تزداد فيه الأزرار السهلة بطريقة ما للعرض للحظة - وهذا هو سبب تقليلها هنا.

basoozaxekon يرجى اختبار إذا https://github.com/Mudlet/Mudlet/pull/2945 على إصلاح المشكلة التي يصف هنا. شكرا لك!