Looks doable. As I understand it it's basically drawing a texture in a circle with some smoothing for antialiasing. Kirigami's ShadowedTexture/ShadowedImage can do all this. It would also remove the need for the extra underlay rectangle since it already uses the fill colour underneath the image.

This seems to use ShaderEffect purely as a way of doing layers. The actual graphical effects used come from QtGraphicalEffects, so assuming that works this doesn't need any additional porting.

https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/857 adds explicit support to KGlobalAccel for running any arbitrary command - even if the specified command does not have an existing desktop file. With that, it can completely replace the "command" and "K-Menu Entry" items from KHotkeys. The "DBus Command" item can be easily replicated as well, by using "qdbus" or "dbus-send" as application and specifying the right service/object/method as arguments.

Since the focus ring effect for widgets seems to be moving along quite nicely, I think we should consider applying it in more cases. That said, the current selection outline already sort of matches that style.

I rather like the "fork a new process" option personally, since that would make it harder to exploit security problems in the actions. That said, I don't know if that's a concern in the first place.

Personally I agree with the KWin bug report that it doesn't belong in KWin, as this is primarily a notification/audio thing instead of a window management thing.

I'm not a fan of adding all the launcher functionality, that really distracts from something that (I assume) is meant for window switching.

@kossebau I wonder if the new JSON parsing functionality of CMake can help here? It'd mean changing the config to use JSON, but it would avoid the entire parsing stuff.

QAction is now in QtGui, but cannot (yet) be used with QtQuick Controls. I created https://bugreports.qt.io/browse/QTBUG-92195 about that.

What happens if you force toolbar header style on mobile? As far as I know there is nothing special excluding actions from the toolbar, it's just that we use a different header style on mobile, so it should just display your contextual actions.

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.

A simple solution here would be to turn this into a factory method that simply returns a new QAction and then leaves it up to the caller to do the connections separately. That would remove the need for old-style connects while still having a "standard" action function. That said, if the only concern of that function of that function is the icon name I don't think it's very useful.

(well, even ksysguard doesn't have to remain named this ugly way, the rewrite could be an occasion to name it less horribly)

Will continue this on Gitlab.