Zren added a comment.
The Instantiator pattern will not work.
https://i.imgur.com/CVKMnnU.png
"content" is PlasmaComponent.ContextMenu's " default property (the list of
child objects like MenuItem).
drosca added a comment.
In https://phabricator.kde.org/D2314#59454, @colomar wrote:
> However, all the actions in the context menu must be available in the main
UI as well.
> So, this patch is good to go, but there needs to be a way to do these
things without the context menu as
colomar added a comment.
Sorry for not replying earlier.
There is nothing that speaks against offering this context menu. However, all
the actions in the context menu must be available in the main UI as well. Due
to discoverability reasons, context menus must never be the only way to
drosca added a comment.
In https://phabricator.kde.org/D2314#58816, @Zren wrote:
> All I did was copy the Menu widget's pattern (sorta) since it was the first
example I could find.
Yeah, PlasmaComponents.ContextMenu sucks but if possible, I would prefer the
declarative approach
Zren added a comment.
> Do we need to do it programatically?
All I did was copy the Menu widget's pattern (sorta) since it was the first
example I could find. It would need to populate hundreds of menu's (most
unused), so that makes sense that it would do things dynamically.
Not
davidedmundson added a comment.
Edit: sorry didn't see drosca replied.
Wait till the VDG reply before doing any changes (as you don't want it to be
wasted)
REPOSITORY
rPLASMAPA Plasma Audio Volume Applet
REVISION DETAIL
https://phabricator.kde.org/D2314
EMAIL PREFERENCES
davidedmundson added a comment.
Do we need to do it programatically? It's should be do-able in a declarative
way with Instantiator
ContextMenu
{
MenuItem {
text: i18n("Mute");
...
}
MenuItem {
text: i18n("Default");
