Summary:
Makes it work out of the box for both GTK 2 and GTK 3 applications.
Since both krdb and kde-gt-config overwrite their respective `gtkrc-2.0` we use a watcher to re-add our config key afterwards.
Test Plan:
Tested Pluma (Gtk3), now has global menu
Tested Gimp and Inkscape, now have global menu
When module isn't installed, prints a warning on console, shouldn't be too bad
Reviewers: #plasma, davidedmundson, fvogt, hein
Reviewed By: #plasma, hein
Subscribers: cgiboudeaux, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D15315
Summary:
Makes it work out of the box for both GTK 2 and GTK 3 applications.
Since both krdb and kde-gt-config overwrite their respective `gtkrc-2.0` we use a watcher to re-add our config key afterwards.
Test Plan:
Tested Pluma (Gtk3), now has global menu
Tested Gimp and Inkscape, now have global menu
When module isn't installed, prints a warning on console, shouldn't be too bad
Reviewers: #plasma, davidedmundson, fvogt, hein
Reviewed By: #plasma, hein
Subscribers: cgiboudeaux, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D15315
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.