Summary:
This brings numerous advantages such as:
- easier admin configuration with drop-ins, overrides and multiple
hooks throughout (and only having to learn one tool)
- session cleanup on exit, avoiding that occasional part where shutdown
hangs
- startup that actually knows when things are up
- race free autostart and DBus activation at once
- logs that rotate are split by service and usable
- resource management through slices and cgroups (the part I want)
Over the past 2 years I've been trying to tidy up and encapsulate the
relevant parts of startup into the binary plasma-session so that we can
just runtime swap out that one part and supporting both paths will be
easy.
Support is toggleable via cmake flag, as it seems like it should be a
distro decision, especially as we will require a specific systemd with
the xdg-generator.
KDED/kwin/other services are attached to the relevant repo.
Task T11914
Differential Revision: https://phabricator.kde.org/D28305
squash
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 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
* 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.
Volker Krause
Laurent Montel
Nicolas Fella
David Edmundson
Kai Uwe Broulik
Eike Hein