SUMMARY When you open a plasmoid configuration dialog, the page has the usual Kirigami page header. When you then open another one, it will not have a header, and instead a warning is printed to the effect of "Cannot assign QObject* to PageRow_QMLTYPE_1749*" STEPS TO REPRODUCE 1. Right-click IOTM, Configure IOTM (don't close it) 2. Right-click System Tray, Configure OBSERVED RESULT System Tray configuration dialog pages have no header (except Entries) EXPECTED RESULT System Tray configuration dialog pages have headers SOFTWARE/OS VERSIONS Operating System: Fedora Linux 41 KDE Plasma Version: 6.3.80 KDE Frameworks Version: 6.13.0 Qt Version: 6.8.2 Kernel Version: 6.13.7-200.fc41.x86_64 (64-bit) Graphics Platform: Wayland Processors: 4 × Intel® Core™ i5-6200U CPU @ 2.30GHz Memory: 16 GiB of RAM (15.5 GiB usable) Graphics Processor: Intel® HD Graphics 520 Stock Fedora 41 Plasma has the same issue ADDITIONAL INFORMATION ConfigEntries in System Tray sets a custom header, which may be relevant? Instrumenting Kirigami.Page with some debug output shows that it apparently tries to set the PageRow of the first dialog, which fails, not the dialog that the page is actually in. I suspect this is a bug in Kirigami Page or maybe ColumnLayout/PageRow, but I'm not quite sure. I also suspect that bug 497616 is the same underlying issue, as I get a similar debug output and error message - it tries to put the page header of the KNewStuff Dialog into the global toolbar for systemsettings.
Can reproduce! How bizarre. It actually seems to be specific to the System Tray; if that's the second config dialog you open, the header isn't there. If the second widget is anything else, then the header does appear, bug slides in with an animation (funky!). Do you see that too?
(In reply to Nate Graham from comment #1) > Can reproduce! How bizarre. It actually seems to be specific to the System > Tray; if that's the second config dialog you open, the header isn't there. > If the second widget is anything else, then the header does appear, bug > slides in with an animation (funky!). > > Do you see that too? I have seen some sliding in sometimes, but I can reproduce it with other config dialogs as well. E.g. open a Konsole Profiles config dialog, then IOTM - IOTM has no header on any of the pages. Window List, same, also Kickoff. The main exception are pages that have something on the header, like a search bar - those are still displayed even if another dialog is already open. But there can only be one of these at a time - if you try to open a second one, the first one will close. E.g. Open Weather Report, then open Digital Clock - Weather Report closes. (Similarly with a Folder View with !2902 applied, Digital Clock closes.) If you start with a dialog that has all the headers and it's replaced by another dialog, the headers are there on the second dialog (that is now the only one). But if it replaces a dialog with (some) headers missing, it'll stay missing E.g. from zero dialogs: Digital Clock -> Weather: Weather has headers on all pages Kickoff -> Digital Clock -> Weather: Weather has headers on the first page, but not on any of the others. In those cases I also get the warning "qrc:/qt/qml/org/kde/kirigami/layouts/FormLayout.qml:88:5: Unable to assign SimpleKCM_QMLTYPE_3073_QML_3082 to ScrollablePage_QMLTYPE_1416" rather than "file:///home/wolki/kde/usr/lib64/qml/org/kde/kirigami/Page.qml:182: Error: Cannot assign QObject* to PageRow_QMLTYPE_2626*" But I suspect it's still the same thing, Kirigami gets confused and tries to load components in the other window. Maybe something wrong with the reparenting of loaded pages?
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kirigami/-/merge_requests/1746
Git commit b2b8ea5f9b8560ad7fb6abbfad1928005a634daf by Marco Martin. Committed on 01/04/2025 at 10:39. Pushed by mart into branch 'master'. Workaround for multiple engine types registration make the row property an Item instead of a PageRow as a workaround for https://bugreports.qt.io/browse/QTBUG-120189 This can be reverted when frameworks will depend from Qt 6.9 Related: bug 497616 M +3 -1 src/controls/Page.qml https://invent.kde.org/frameworks/kirigami/-/commit/b2b8ea5f9b8560ad7fb6abbfad1928005a634daf