Instead of comparing the state of the action to the action name, compare it to the argument the action will invoke it with.
In contrast to checkboxes, which are independent actions with a boolean state, radio menu items all refer
to the same action (e.g. "Zoom") and then pass the new state ("zoom-100", "zoom-200", etc) as target when invoking the action.
CCBUG: 418385
Differential Revision: https://phabricator.kde.org/D27885
According to documentation [1] a menu item has a target attribute, which is "the parameter to pass when activating the action".
Furthermore, the action "Activate" method specifies "If the action activation requires a parameter then this parameter must
be given in the second parameter (av).". Also implements a TODO in the code.
[1] https://wiki.gnome.org/Projects/GLib/GApplication/DBusAPI
CCBUG: 418385
Differential Revision: https://phabricator.kde.org/D27884
This was an experiment of showing the app menu in a "Menu" submenu but it would complicate
the mapping logic as there's suddenly a menu layer "above" the main menu, so that should
proably go into appmenu applet instead.
This way we can monitor both appmenu and window menu simultaneously and (theoretically)
switch between one and the other on the fly.
The Menu class is now Window as it encapsulates an entire window with everything that belongs to it.
All DBusMenu-specific code is in Window whereas GMenu-stuff is in Menu and so it's less entangled
Alexander Lohnau
Kai Uwe Broulik
Laurent Montel
Yuri Chornoivan