+1, I think we really need this as we continue the move with porting apps to QML and writing large and complicated QML apps.

I'm not so sure we need XML (or JSON) to create something similar to KXmlGui for QML because QML is already a good enough language to declare a list of actions in a declarative way. The more fundamental problem is that Kirigami is a tier 1 framework and as such can't depend on other frameworks like KConfig. This is a problem because we would need to save the states of the toolbars for editable toolbars, split view dimension for resizable columns, read from standard shortcuts with KStandardShortcut, save window dimensions, ...

This would help to make Kirigami applications more integrated with the other KDE applications but also make it more complicated for third parties to use Kirigami.

@mart thoughts?

KConfig is Tier 1, so I don't see any reason why third parties could use Kirigami, but not KConfig.

I think the point is that a Tier 1 framework must not depend on another Tier 1 framework. So, the solutions are to either increase the Tier of Kirigami or to introduce another umbrella framework similar to KXmlGui, which does the GUI generation based on Kirigami and KConfig (I would prefer the latter personally).

This has been mentioned a few times in chat, Do we gain anything by remaking a monolithic beast like KXmlGui? I have been thinking about this, and I think it would be much better to have small independent blocks that you can put together. In other words, have a "WindowState" object that you can point at any QML window to have its properties saved/restored. Or have an "EditableToolBar" item that can be used to replace the fixed toolbar of Kirigami. This has the advantage that these objects become small, focussed things with a clear purpose, rather than a complex beast where you don't really know what is going on.

My reading of this task is that it's not asking for a literal re-implementation of KXMLGui so much as a central place to put desktop-relevant QML components so that functionality doesn't have to be re-implemented for every QML app. Maybe this is more like the QML version of KWidgetsAddons than the QML version of KXMLGui.

My reading of this task is that it's not asking for a literal re-implementation of KXMLGui so much as a central place to put desktop-relevant QML components so that functionality doesn't have to be re-implemented for every QML app.

That's quite broad.

My understanding of the task was that it was purely about the feature request for editable toolbars and whether we have existing code that, if refactored, would be sharable.

Perhaps @nicolasfella can clarify for us. :)

I don't have a clear vision/proposal for this.

My motivation was mostly investigating code sharing for editable toolbars, but other features of KXmlGui are interesting too. I very much agree with what Arjen is saying though.

Yeah, I agree with Arjen too.

With Kalendar we ended up using quite a bit of stuff from KConfigWidgets and KXmlGui.

Our primary actions objects are QAction, with wrappers to QQC2.Actions and Qt labs menus. Using QActions allows us to move some logic to C++, support KAuthorized::authorizeAction, but also add use KShortcutsDialog from KXmlGui and a copy of the internal model from KCommandBar.

Currently, this has the problem of depending on QWidgets (but it is a non-issue for Kalendar since Akonadi and other PIM libs that we depend have a much bigger dependency on QtWidgets) but with Qt6 this isn't the case anymore. On the upside, this allows reusing many parts of code from KDE and have all this code in C++, something that wouldn't be possible if we were using QQC2.Action (without depending on private api).

From my point of view, this looks like the best way to move forward with a powerful application written in QML, but for that, we will need to reopen T14299 and possibly try to move models from KConfigWidget and KXmlGui lover in tier (e.g. kcommandbar, kconfigeditor internal model) so that we don't depend on QtWidgets for this.

Does that make sense?

That makes a lot of sense to me!

Besides toolbars, KXmlGui also provides KShortcutsDialog which is a free shortcut editor. This will also be useful in any app that has lots of shortcuts.