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
appmenu-gtk-module always announces a menu bar even if there is none, so we always
request a menu bar and when it turns out to be empty and have actually have an app menu
to fall back to we'll use that instead.
Also init after having connected to signals, this might fix issues where the menu won't show up the first time
an application window shows as the menu might have requested setting the window properties before we connected
to that (unlikely, but who knows).
This is in preparation for being able to fall back from window menu to application menu should the former be empty.
It's perfectly fine for a window to have a menu only consisting of application actions.
Also improve update logic by signalling individual item changes rather than having it rebuild
the menu every time. Also optimize the menu change handler to just update items when the same
number of items is inserted and removed at once
* 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
When the window goes away there's no x window to remove properties from and also the
DBus interface for the menu seems to go away before we could unsubscribe
* Send delayed reply when we aren't subscribed yet in GetLayout
* Show keyboard shortcuts (crude)
* Add some icons for known actions (even more crude)
* Support GTK actions stuff, including action enabled/visible/checkable
* Action invocation
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.
Fabian Vogt
Kai Uwe Broulik
Eike Hein
Friedrich W. H. Kossebau