https://bugs.kde.org/show_bug.cgi?id=508377
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #17 from [email protected] --- I just started getting impacted by this bug after updating my packages. Currently running CachyOS with: kirigami 6.29.0-1.1, kirigami-addons 1.13.1-1.1, plasma-workspace 6.7.4-3.1, qt6-declarative 6.11.2-1, libplasma 6.7.4-1.1. Like other commenters (#13-15), I also have System Monitor widgets on desktop/panels. I took a look into the Kirigami code to see if I could figure out why this was happening. Maybe this will help someone fix the bug (I don't have a KDE dev/test environment set up right now). Happy to provide any followup information to help get this resolved. MECHANISM IconPropertiesGroup (src/primitives/IconPropertiesGroup.qml) is a pure-QML type. InlineMessage.qml uses it as a grouped property type: // src/templates/InlineMessage.qml:187 > property Primitives.IconPropertiesGroup icon: Primitives.IconPropertiesGroup > {} Every qmldir in the org.kde.kirigami.* modules carries a "prefer :/qt/qml/org/kde/kirigami/<module>/" directive telling the QML engine to resolve that module's QML files from the compiled Qt resource (qrc:) rather than disk. However, when something in the same plasmashell process independently triggers module resolution via the on-disk path first (file:///usr/lib/qt6/qml/org/kde/kirigami/primitives/IconPropertiesGroup.qml) (for me and other commenters in this thread, that is the System Monitor sensor-widget QML), the QML type loader caches and registers a synthetic QMetaType for that URL (IconPropertiesGroup_QMLTYPE_NNN). This registration is keyed by the resolved QUrl, so the "qrc:" copy and the "file:" copy of the identical source are registered as two distinct but incompatible classes. Whichever copy gets registered first "wins" for later type lookups within that import context. When InlineMessage.qml (itself compiled into the "qrc:" resource) is subsequently loaded and tries to bind its icon property's declared type against the instantiated Primitives.IconPropertiesGroup {}, it can end up with a declared-type/instantiated-type mismatch if the two resolved through different URL schemes, which leads to: > Cannot assign object of type "Primitives.IconPropertiesGroup" to property of > type "IconPropertiesGroup_QMLTYPE_267*" as the former is neither the same as > the latter nor a sub-class of it. This explains the reported symptoms: • Nondeterminism: the QMLTYPE_NNN id changes every plasmashell restart, since it depends on process-specific QML type-registration order • System Monitor widgets triggering it (comments #13-15): they appear to be the first consumer to force a disk-path resolution of org.kde.kirigami.primitives before Kirigami's own components get a chance to load consistently via "qrc:" • Not reproducible outside plasmashell: qml, kcmshell6, etc. only ever load Kirigami through one path per process instance, so there's no competing resolution to race against WORKAROUND Commenting out every "prefer:" line in /usr/lib/qt6/qml/org/kde/kirigami/**/qmldir and restarting plasmashell resolves it. With no preference set, the engine consistently uses the same resolution path (disk) for both the property's declared type and every instantiation, so there's no longer a competing "qrc:" duplicate to conflict with. This is a streamlined workaround from earlier comments: > sudo find /usr/lib/qt6/qml/org/kde/kirigami -name qmldir -exec sed -i > 's/^prefer /#prefer /' {} \; > systemctl --user restart plasma-plasmashell.service Note that if you apply this workaround, any update to the the kirigami will likely revert your changes since these are system files are owned by the package. SUGGESTED FIX (?) The QML type loader needs to deduplicate registration of grouped-property types like IconPropertiesGroup regardless of which URL scheme ("qrc:" vs "file:") first resolved them, or Kirigami needs to guarantee prefer is honored for all consumers of its modules within a process, not just ones that import it directly after the module has already been "claimed" by an unrelated disk-path load. Possibly worth reporting upstream against Qt's QQmlTypeLoader/module resolution as well, since the "dual registration by scheme" behavior is the root cause. I'm not versed in KDE/Kirigami/Qt code enough to know which of these options is "correct", so take my suggestion with a grain of salt. -- You are receiving this mail because: You are watching all bug changes.
