https://bugs.kde.org/show_bug.cgi?id=508377

[email protected] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[email protected]

--- Comment #11 from [email protected] ---
Still happening here with Kirigami 6.29.0 and Plasma 6.7.4 on CachyOS (Arch
packages, Wayland). Same as comment #8 — network and volume applets just don't
open their popups anymore:

error when loading applet "org.kde.plasma.networkmanagement":
  qrc:/qt/qml/plasma/applet/org/kde/plasma/networkmanagement/main.qml:60:25:
Type PopupDialog unavailable
 
qrc:/qt/qml/plasma/applet/org/kde/plasma/networkmanagement/PopupDialog.qml:110:22:
Type ConnectionListPage unavailable
 
qrc:/qt/qml/plasma/applet/org/kde/plasma/networkmanagement/ConnectionListPage.qml:26:5:
Type Kirigami.InlineMessage unavailable
  file:///usr/lib/qt6/qml/org/kde/kirigami/controls/InlineMessage.qml:14:1:
Type KT.InlineMessage unavailable
  qrc:/qt/qml/org/kde/kirigami/templates/InlineMessage.qml:187:51: 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.

The volume applet fails the same way via MicrophoneTestView.qml:60:9. One thing
I haven't seen mentioned in this bug yet: the desktop containment is hit too,
FolderView.qml:1269:13 gives the identical Kirigami.InlineMessage error. So
it's
not just panel applets.

Since comment #5 says this isn't reproducible on master, I tried to narrow down
what on my end could be causing it. Turns out: nothing. I ran plasmashell with
a
completely empty config profile — default panel, no third-party widgets, none
of
my settings — and it still fails, same two applets:

  systemctl --user stop plasma-plasmashell
  T=$(date '+%Y-%m-%d %H:%M:%S')
  mkdir -p /tmp/freshconfig
  XDG_CONFIG_HOME=/tmp/freshconfig setsid plasmashell --no-respawn &
  # give it ~45s to load the default panel
  journalctl --user --since "$T" _COMM=plasmashell | grep -c
IconPropertiesGroup

Small warning if anyone wants to repeat this: plasmashell logs to the journal,
not to stdout. My first attempt redirected stdout to a file, got an empty file,
and I briefly thought the fresh profile had fixed it. It hadn't.

Before that I also disabled all six of my third-party plasmoids and restarted —
no change at all, exact same error count. So it's not a widget of mine.

Other things I checked that all came back clean: no leftover or unowned files
under /usr/lib/qt6/qml/org/kde/kirigami, no second Kirigami copy anywhere in
the
import path, QML_IMPORT_PATH and QML2_IMPORT_PATH unset, ldd on the Kirigami
plugin .so files resolves fine, and the "prefer :/qt/qml/org/kde/kirigami/..."
line is present and consistent in the qmldir of the main module and of
controls,
templates, primitives and platform. Everything is fully up to date and the
package versions are consistent with each other (qt6-base and qt6-declarative
6.11.2, plasma-workspace 6.7.4-3.1, libplasma 6.7.4-1.1).

What does seem relevant is that it only goes wrong inside plasmashell. A plain
QML file that imports org.kde.kirigami and instantiates Kirigami.InlineMessage
loads without complaint under /usr/lib/qt6/bin/qml, and kcmshell6 is fine too
(tried kcm_mouse, kcm_users, kcm_notifications, kcm_networkmanagement,
kcm_pulseaudio — no errors in any of them). plasmashell is the one process
where
everything shares a single QML engine.

Looking at the failing lines, the two halves resolve differently:
org.kde.kirigami.controls comes from disk (file:///usr/lib/qt6/qml/...) while
org.kde.kirigami.templates comes from the compiled resource (qrc:/qt/qml/...),
and each registers its own IconPropertiesGroup. That would fit the load-order
dependency people have described, and the QMLTYPE number does change between
restarts (267 for me, 256 in comment #8). Might also explain why it doesn't
show
up on master if that's being tested outside plasmashell — though I don't know
the Kirigami internals well enough to say whether that's actually the
mechanism.

Happy to test patches or grab more logs if that helps.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to