expanding the inhibit spec
Àlex Fiestas
afiestas at kde.org
Sun Jan 12 07:42:59 PST 2014
Having read the whole thread (and about to write the power management support
for KDE5/Plasma 2) I think we do need a session daemon handling the things
that are out of logind1 scope and its api must be in fd.o, but I would like to
avoid duplicating api with it, and even worse end up proxying calls.
The way we have currently implemented logind1 support is just by adding one
inhibition with description "KDE Handlers this" which sucks since systemd is
not aware of what applications are inhibiting. This is valuable information we
must have in systemd in the future and that's why on future releases (KDE5)
the plan was to talk directly to logind1 whenever possible.
Distributions that don't want to use logind1 can implement a dbus service with
the same api, maybe we can move the inhibition api to its own service to make
it more obvious that that api doesn't depend on all the other logind1
features.
So in short:
+1 to have a common fd.o spec for things that can't be in logind1
-1 to duplicate api with logind1
Cheers.
More information about the xdg
mailing list