Inhibits, and the new world order

Once upon a time there were three inhibit API’s:

Obviously, this has a few big flaws:

  • An application might have to inhibit three services, using slightly different methods
  • gnome-screensaver has to expose lots of low level icky stuff for g-p-m to consume
  • We’ve got a screensaver doing idle detection
  • We’ve got gnome-power-manager writing into gnome-screensaver GConf keys to get the timeouts correct
  • It’s not possible to prevent logout or user switching
  • The hand-off between the session and power manager is poorly defined, so we get stupid libnotify popups rather than nice dialogue integration.
  • We don’t integrate with presence services, so we just ignore away/busy/idle status.

Basically, we need the session manager to take care of the all registrations and handle the interactions. Luckily, this is what Jon McCann has done in gnome-session.

These new interfaces are session management done right. Of course, this breaks the old world order of inhibiting gnome-power-manager and gnome-screensaver. For the 2-26 series all inhibits are proxied by g-p-m and g-s to gnome-session, so everything should pretty much just work like before. But, early in the 2-27 cycle we’re going to remove this compat code and everything will have to go through gnome-session. For most code it’ll just be a couple of lines changed and behind the scenes it’s a much simpler and more powerful design.

Like some of the other changes we are making at the moment (DeviceKit, PulseAudio, KMS) this is a new way of doing things, and things might temporarily break. They’ll be regressions, but things can be fixed quickly and most importantly, correctly. What we were using before just wasn’t good enough. With this new framework, we can do it right for GNOME 3.0.

Published by


Richard has over 10 years of experience developing open source software. He is the maintainer of GNOME Software, PackageKit, GNOME Packagekit, GNOME Power Manager, GNOME Color Manager, colord, and UPower and also contributes to many other projects and opensource standards. Richard has three main areas of interest on the free desktop, color management, package management, and power management. Richard graduated a few years ago from the University of Surrey with a Masters in Electronics Engineering. He now works for Red Hat in the desktop group, and also manages a company selling open source calibration equipment. Richard's outside interests include taking photos and eating good food.

19 thoughts on “Inhibits, and the new world order”

  1. Will there ever be a possibility to inhibit just one screen? Say prevent the screensaver from blanking a monitor with important stats displayed or the one with a movie playing.

  2. Will the session manager now have the concept of the session being idle (e.g. for changing your presence in applications like Empathy)?

  3. Corey: HAL still exists, although applications don’t need to use it. Long term HAL is going to be phased out in favour of DeviceKit-* daemons, so it’s not really of massive concern. The old HAL interface was clunky, and it was just not possible to plumb it into the session like we needed to.

  4. By the way, would you read this mail:

    which is about this very problem? I guess now is the time to tackle it.

    There’s an old bug about this too:

    Ideally, I think we would need:
    – a fd.o standard D-Bus interface for this (we absolutely need to avoid a KDE/GNOME problem with inhibit)
    – 3 different inhibit levels that prevent resp. screensaver, automatic suspend, and manual suspend (for CD burning, etc.)


  5. Right, HAL is going to die. But then why not push this kind of interface into devkit? Or are we going to have another go ’round, where gnome-session proxies to a devkit interface in the future when that is more settled?

  6. @hughsie: no Empathy is not wired up yet. If this is landing in GNOME 2.26, I should make it work. It should be straight forward enough.

    Out of interest, is the DBus API documented somewhere?

  7. @Corey: Well, DK-p is system based, and gnome-session is session based. ConsoleKit is aware of each session, and so I would imagine this goes through ConsoleKit too.

  8. I don’t quite follow why “It’s not possible to prevent logout or user switching” is a flaw. Is it for cases where, e.g. you’re burning a CD, and if you log out, the burner will get terminated mid-job, resulting in a brand new coaster for your tea cup?

    What about user-switches then? Okay, every time I tried to use the fast user switcher applet, my X server promptly crashed, so I can see how it’s the same thing as a logout, but, assuming this gets fixed, what’s the harm?

  9. From the sounds of it, this change will adversely affect Xubuntu. We use gnome-screensaver and gnome-power-manager to offer user friendly power management options to our users. I’m all for better architect but am I correct in understanding that these changes will make g-p-m and g-s-s depend on gnome session manager? : (

  10. @Cody: Well, no, not really. It does make applications depend on a session process providing org.gnome.SessionManager, but you could code that up in about 50 lines of python if you really wanted.

Comments are closed.