Inhibiting

Disclaimer: this post is mainly for Developers!!

That said, I thought a blog post would have been better to explain the new, cool Inhibition feature in PowerDevil/Solid. On my message to the list I’ve been unclear, and let me say _don’t use the DBus interface_ but the provided methods. So let me show a sample of an application inhibiting suspension.

void InhibitTest::setInhibition()
{
kDebug() << "Setting inhibition";
m_cookie = Solid::PowerManagement::beginSuppressingSleep("We're testing inhibition, don't bother us!");
}

void InhibitTest::releaseInhibition()
{
kDebug() << "Releasing inhibition";
Solid::PowerManagement::stopSuppressingSleep(m_cookie);
qApp->exit();
}

int main(int argc, char **argv)
{
KAboutData aboutData( "testinhibit", 0, ki18n("Test Inhibition"),
"1.0", ki18n(""), KAboutData::License_GPL,
ki18n(""), ki18n(""));
KCmdLineArgs::init(argc, argv, &aboutData);
KApplication app(true);
app.setQuitOnLastWindowClosed(false);
InhibitTest test;
test.setInhibition();
QTimer::singleShot(15000, &test, SLOT(releaseInhibition()));
app.exec();
}

Seen how easy it is? You just have to call the static method Solid::PowerManagement::beginSuppressingSleep() specifying a reason for your inhibition, and store the cookie it returns. If you try to suspend after you call it, you get this:

Inhibiting suspension, dude

Inhibiting suspension, dude

Yeah, I’ve also improved notifications, but this will come in a future post šŸ˜€ The user will be notified and suspension won’t happen.

When you want to release the lock, Solid::PowerManagement::stopSuppressingSleep() is your friend, just pass it the cookie you stored before (you did store it, right?), and that’s enough.

This feature is really cool. I see a lot of cool usages, for example in video players, package managers, whatever else. And given the fact it’s just a private member+2 lines of code, integration is really easy šŸ™‚

P.S.: A post with all new cool stuff in Powerdevil is coming, and PowerDevil 1.3.0 for KDE4.1 is coming too šŸ™‚

~ by Dario on 2 October, 2008.

17 Responses to “Inhibiting”

  1. And where is the button: “I don’t care that some jealous developer thinks his
    program is important. Suspend NOW!”

    Btw. Typing blind is bad. Have a look at you page in akregator!

  2. What about if the applcation crash before releasing?

  3. @Mike the button will still work. This feature is for apps that don’t want the machine tot suspend automatically after some idle time for example.

  4. It sounds really good idea. I think a lot of programs could make use of this. But I think it should use D-bus as that would make interoperability with Gnome and other Desktops possible. That is gnome programs running under KDE desktop and KDE programs under Gnome desktop would still be able to stop suspension.

  5. Hm. It sure would be nice if we could get a org.freedesktop.PowerManagement spec ratified and used for this stuff so application developers that need to live in both GNOME and KDE environments can have a sane way of dealing with this? Any progress towards that, do you know?

  6. Good job. This seems like a really good idea to me šŸ™‚

  7. Very nice!
    But I would like to raise my concern as well, about interoperability with gnome. Specifically, like mentioned in other comments, why not use org.freedesktop.PowerManagement and be desktop agnostic?

  8. Does any of you find KNotify extremely ugly and out of place on the KDE4 desktop?

  9. Hmm, wouldn’t it be better if watching a video automatically sets the “Presentation profile”, where you don’t get a screensaver and automatically suspending is deactivated as long as the video lasts?
    Or where you’d call a function with flags (in fact that would not be in Solid then) –> iAmAFunction( NoScreenSaver | NoSuspend | NoGeneralNotification )
    and
    iWantToExplain( ki8n(“Because I want to discharge your batteries, hahahah”) )

    Yeah, I don’t have a clue how to do that. šŸ˜€

    Nevertheless very good that you give developers the chance to have us finish watching our videos. šŸ™‚ Though I agree that there should be an option like “ignore per apps settings and allways suspend …”, maybe with a tooltip what could happen.

  10. You mentioned package managers and the like–will it also be possible to do something like “delaying suspension until task complete (ETA 1:27)”?

  11. @Jason, @Khashayar, @Robert: I assume that this call *does* use DBus, internally
    http://people.freedesktop.org/~hughsient/temp/dbus-interface.html
    powerdevil is already pretty close to implementing this spec nicely. Some work on the interfaces remains to be done, interoperability should not be a problem (i.e. KDE apps under GNOME ‘just working’, and GNOME apps under KDE in the same way.

    @hmm: In trunk/, you can also get knotify plasma-style

    @mat69: That’s the plan :>

    @ThomasK: The packagemanager would inhibit suspend for as long as it’s busy and then release the lock, the machine will then start idle time suspending

  12. @sebas: What does the plasma style look like?

  13. @hmm top-secret right now, have some patience šŸ™‚

  14. @hmm: There have been blogs (w/screenshots) about the notification plasmoid (a.k.a. plasma style).

  15. Looks great! How does it handle multiple applications trying to manage inhibition? For example; what if I had a video window and a presentation window both running?

  16. What’s the use case for this? What happens when an app that suppressed sleep crashes?

  17. @Gordon: That’s why the inhibit function returns an integer.

Leave a comment