در این نسخههای آتی پارچ که ما نصب کننده رو بازطراحی کردیم؛ یک سری مشکلات با کالامارس پیش اومده بود منجمله اینکه بخشهایی از qmlها رو با qt5 مدیریت میکرد که باعث میشد textboxها کار نکنن و براش نیازمند پاس دادن وریبل xcb باشیم که در گنوم و هایپرلند کار نمیکنه.
درنهایت هم کالامارس رو فورک کردیم؛ و این پچ رو روش اعمال کردیم:
https://github.com/parchlinux/calamares/commit/7cac7c222ab5d51ed83aefea379f05bcc1dc9c8f
توضیحات فنی برای افراد فنی:
علت اصلی این بود که QQuickWidget بهجای داشتن یک پنجرهٔ Wayland واقعی، سین QML رو داخل یک QQuickWindow آفاسکرین رندر میکنه و فقط نتیجه رو داخل ویجت میزبان کپی میکنه. در نتیجه آبجکتی که QGuiApplication::focusObject گزارش میده با آبجکتی که واقعاً داخل سین QML فوکوس گرفته یکی نیست. پروتکلهای متنورودی Wayland مثل text-input-v3 دقیقاً بر همین focusObject تکیه دارن، برای همین کامپوزیتور هیچوقت نمیفهمید فیلدی برای تایپ فوکوس شده. روی X11 این مشکل اصلاً خودش رو نشون نمیداد چون فوکوس اونجا در سطح پنجره مدیریت میشه و ربطی به اینکه محتوای داخلی چطور رندر شده نداره، برای همین با فورس کردن xcb کار میکرد.
راهحلی که در پچ اعمال کردیم یک پل فوکوس بین QQuickWindow و QQuickWidget میزبانشه. تابع installQuickWidgetFocusBridge به سیگنال QQuickWindow::focusObjectChanged وصل میشه، با Qt::UniqueConnection که اگه چندبار صدا زده بشه دوباره کانکت نکنه. هر بار که آبجکت فوکوس داخل سین عوض میشه، اگه اون آبجکت یک QQuickItem باشه که پرچم ItemAcceptsInputMethod روش ست شده، یعنی واقعاً قراره چیزی توش تایپ بشه، فوکوس واقعی ویجت رو با setFocus میذاریم و بعدش روی windowHandle پنجرهٔ اصلی درخواست activate میفرستیم. این کار باعث میشه focusObject سراسری برنامه با چیزی که کاربر واقعاً داره باهاش کار میکنه هماهنگ بمونه و کامپوزیتور بتونه فوکوس متنورودی رو درست مسیر بده.
این پل رو هم توی سازندهٔ QmlViewStep صدا زدیم و هم توی onActivate، همراه با یک setFocus صریح روی m_qmlWidget، چون هر بار صفحهٔ جدیدی از کالاماریز فعال میشه باید فوکوس دوباره صراحتاً ست بشه وگرنه اولین فیلد صفحه اصلاً فوکوس نمیگیره. با این پچ مشکل روی گنوم و هایپرلند بدون نیاز به فورس کردن QT_QPA_PLATFORM=xcb حل شد.
@ParchLinux | پارچ لینوکس