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 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
* Cleanup code and use categorized logging
* Monitor action changes (e.g. toggled state of checkbox)
* Monitor menu changes (e.g. menu label changed)
* Handle when app has no menu on startup but gets one later
* Disable GTK menu bar when we're running
This will mediate between applications using GMenu (like LibreOffice) and expose their menus
using our DBusMenu protocol so that no changes on our global menu side is needed.
WIP: So far all it can do is detect windows with GMenus attached to it, register a DBus service
and then announce the corresponding DBusMenu paths.
Kai Uwe Broulik
Friedrich W. H. Kossebau