I assume you are talking about PC2 vs PC3?

@ndavis didn't you do some investigation around this?

added some applets that depend on this (wasn't really thorough) but it's pretty clear that this is a pretty important task

In T14315#255483, @nicolasfella wrote:

@ndavis didn't you do some investigation around this?

I also talked with @mart a bit about this. PC2 Menu is really more like the Platform Menu from Qt Labs and is not based on QQC1. PC2 MenuItem is just a QQuickItem with some properties and no visual content and its action property uses a QAction (not available to QML). It may as well just be a plain QObject like Platform MenuItem from what I can see. They probably could both be added directly to PlasmaExtras, but I think this is probably also a good opportunity to improve them since we can make an API break here.

Instead of having a QQuickItem based MenuItem with no visual content, we could just expose QAction and QActionGroup to QML for use in the Menu as things like PlasmaExtras.MenuAction and PlasmaExtras.MenuActionGroup. QAction doesn't come with every property we might want it to have, but we can add the missing properties by making a subclass. Most of the missing properties can already use getters and setters from QAction's public API (e.g., setSeparator, isSeparator).

Maybe it would also be a good idea to allow the Menu to accept a model? Either a model of data with the ability to set a delegate (a MenuAction configured based on role data from the model) or a model/list of QActions so that QAction can be used for C++ models and MenuAction can be used for QML models.

If we did that, we could make the actionLists from Kicker's models give a list of QActions instead of just a list of data. That way Kickoff wouldn't need so much JavaScript just to turn the actionLists into items in the context menu.

The problem with a QAction is that it's using a QIcon instead of the icon.name stuff we have in QQuickAction :( I think a better idea would be to try to improve the Platform Menu from Qt labs so that it gets a stable API in Qt 6.3 or so :)

In T14315#255620, @ognarb wrote:

The problem with a QAction is that it's using a QIcon instead of the icon.name stuff we have in QQuickAction :(

I don't think that's a problem. We can replace the icon property with one that accepts a QVariant and determine whether or not the supplied icon is a string, url or QIcon.

I think a better idea would be to try to improve the Platform Menu from Qt labs so that it gets a stable API in Qt 6.3 or so :)

I suppose that's an option too and probably good to do anyway, but then we have to wait until we can use Qt 6.3. We can have something similar and stable in PlasmaExtras now. If we want to make a list of Platform MenuItems for Kicker's actionLists, we'll have to write embedded QML in C++, which is annoying and sub-optimal even if doable.

I suppose that's an option too and probably good to do anyway, but then we have to wait until we can use Qt 6.3. We can have something similar and stable in PlasmaExtras now. If we want to make a list of Platform MenuItems for Kicker's actionLists, we'll have to write embedded QML in C++, which is annoying and sub-optimal even if doable.

Couldn't we potentially just mirror Platform Menu, so we'd still have stable API even if qt killed it? I know it's suboptimal but imo still better than creating another implementation altogether

In T14315#255640, @mikeljohnson wrote:

I suppose that's an option too and probably good to do anyway, but then we have to wait until we can use Qt 6.3. We can have something similar and stable in PlasmaExtras now. If we want to make a list of Platform MenuItems for Kicker's actionLists, we'll have to write embedded QML in C++, which is annoying and sub-optimal even if doable.

Couldn't we potentially just mirror Platform Menu, so we'd still have stable API even if qt killed it? I know it's suboptimal but imo still better than creating another implementation altogether

It's not really a different from anything we already have. It's QMenu with QActions, but declarative instead of imperative. If you have experience with using QQC2 Actions with QQC2 Menu or QActions with QMenu, it'll be familiar.

going back to this task, it probably makes sense to have native context in Kirigami, since it won't get plasma styling anyway *and* it's something that we want for desktop apps anyway. we could even have a Kirigami.Actions based API :V

qt5's new QML_FOREIGN and QML_EXTENDED things with the new c++ type registration stuff give us another option for this: we can just QML_FOREIGN a QMenu and have QML work with those + related types pretty much directly