expanding the inhibit spec

[Ryan Lortie]

hi,

On Thu, Jan 9, 2014, at 7:39, Lennart Poettering wrote:
> No, that is expressly not what I am assuming. All I am saying is that
> this should be abstracted at the client side, and not in yet another
> service in the middle. Because if you proxy all this, then you actually
> break the one case that most of us actually care for (which is the
> logind case)...
> 
> I mean, I am pretty sure that most other inhibition APIs would also try
> to record who actually took the lock, and would thus be affected too if
> you always proxy everything via some other daemon so that everything
> looks like it came from the very same processs...

I agree that this is a weakness.  It's a weakness that could be
addressed by logind implementing this API for itself (or trusting
forwarded information from gnome-session or other designated processes).

I think this is a problem that we already have though, because
GtkApplication is currently doing all inhibit via gnome-session and I
don't plan to change that to use logind directly until we have a more
reasonable way to do so...

> I am not following here. What are you trying to do? THese are platform
> APIs. D-Bus is not a plugin framework to make it possible to avoid
> changing glib or gtk to support different platform backends directly.
> 
> I mean, what I am really not getting here: you are trying to abstract
> something here so that multiple backends are possible. I assume you have
> at least two backends in mind there? Which ones are those? logind is
> one, but what is the other? It can't be Windows, since your proposed API
> uses fd passing, but what is the other backend you want to abstract
> here? FreeBSD? Do they even have an inhibition framewrk?
> 
> Abstracting this with just the vague idea that maybe one day there might
> be a second backend, and that then maybe when that day comes it would be
> better to run that on the session bus sounds just awfully wrong.
> 
> So, what precisely are you trying to make work here?

First, it's a pain for me (with Gtk hat on) to have to test for the
existence of various D-Bus services in order to decide which one I
should talk to.  This is the kind of thing we're used to, though... we
have a bug open about it right now.  I'm using this thread as a way to
resist adding code complexity on my side about it.

It's a whole other issue, though, when we start to talk about
independent app vendors who don't want to use Gtk.  People who want to
make something in SDL and have it just work.  What do we tell them?  I
guess we could start by asking them "what is your intended platform?"

"I don't know.. GNOME?  The freedesktop APIs?  Linux?  systemd-using
systems?"

It turns out that in order to answer this question I actually have to
ask another question: "what type of thing are you trying to suspend?"

If they say "screensaver due to idle", the answer is "GNOME" (because
logind doesn't handle this).

If they say "logout, because I have unsaved files", answer again is
"GNOME".

If they say "suspend, due to idle" or "suspend, because I want to do
cleanup tasks" the answer is now "logind" (or "Linux", if we want to
take the somewhat reasonable approach that logind is universal at least
for Linux systems).

This sort of lack of coherence is at the root of what is bothering me. 
It's bad enough to approach from the standpoint of trying to make Gtk
work... it's nearly unapproachable from the standpoint of third parties.

After that, it only gets worse if they want their app to work nicely on
KDE as well, or maybe some non-Linux system (or a Linux system not using
logind).  There's no good reason that application authors should be
forced to #ifdef the hell out of their code just because they care about
portability.  POSIX isn't pointless, nor is what I'm asking for here.

I'm not saying that this would somehow magically cause FreeBSD to start
working tomorrow, but at least we give the FreeBSD guys a chance to
implement a reasonable/simple interface that would allow them to exist
on the same level of functionality as GNOME+logind+Linux.  Ditto other
desktops.

> > Even that would not make me completely happy, however, because I
> > couldn't handle all of my inhibit needs there (unless you were willing
> > to expand the list of things you support inhibiting, for informational
> > purposes for the session to see).
> 
> "things logind supports inhibiting"? what would those be?

What I meant by this is that logind could start state-tracking for
things that it doesn't care about itself, such as "logout" or "prevent
screensaver".  gnome-session could then watch logind to determine which
flags have been set and decide how to modify its own behaviour based on
that.

Note about "screensaver": I am assuming here that applications may want
to inhibit "idle" for more than one reason.  If I'm downloading a file,
I may want to inhibit suspend-due-to-idle while still allowing the
screen to lock.  If I'm playing a video, I probably want to inhibit
both.

> I'd really prefer if you abstracted this in gtk or glib on the client
> side. I mean, note that for some kind of inhibitors, like for example
> the "idle" inhibitor the backend might not even be a bus service but
> simly some local syscall. "idle" inhibitors are pretty close to android
> wakelocks or suspend blockers in the kernel. It would only be natural to
> expose them behind the same API. Wakelocks are cheap locks, programs can
> take the often and for short periods, and you shouldn't need to involve
> a mandatory bus service with that...
> 
> At the moment I can think of at different three different APIs that gtk
> might want to provide a single API for: kernel suspend blockers, logind
> suspend locks, and gnome-session screen-lock or logout locks. All of
> them would greatly benefit if the actual client would talk directly to
> them: to get the accounting right, to get permissions right and to get
> the latency right.
> 
> Note that if you type "poweroff" on a systemd system right now, and some
> desktop app "foobar" has taken a system shutdown lock, then poweroff
> will actually tell you about that and tell you exactly which
> process/user, and request you retry with "--ignore-inhibit" if you still
> want to shutdown.... Please don't break this. it would be quite a loss
> of usefulness if it would always say "gnome-session" as process...

I agree with all of your arguments here about the value of direct
communication, but I still don't accept that Gtk (and every 3rd party
app developer) should have to go to three different desktop-specific or
system-specific APIs to get the job done.

People do care about portability, and they generally prefer if they can
do it without a huge mess of #ifdef and runtime checking.

As for kernel suspend blocking or wakelocks... well, that's just outside
of the scope of what I'm proposing here.  It's obviously not reasonable
to mediate this sort of this via D-Bus.  It seems like something in GLib
would be more appropriate for that (and probably we'd need to abstract
it, if non-Linux systems ever added support).

Cheers