GNOME Bugzilla – Bug 353077
Ekiga should notify various desktop components when it is in a call
Last modified: 2009-01-29 14:40:29 UTC
I'm fed up with having three bug reports for things I think I'll fix in a single stroke (#330237, #338131 and #338450). The common idea is that when ekiga starts a call, it should notify various desktop components of this, so they act accordingly. 1) the screensaver should not consider the computer as idle (even for an audio-only call) ; this was reported here : https://launchpad.net/distros/ubuntu/+source/gnome-screensaver/+bug/30659 there is some InhibitActivation DBus-method to call it seems. This is discussed here : https://wiki.ubuntu.com/InhibitingGnomeScreensaver 2) the gnome power manager may also have to be notified about it, but probably point (1) already does the trick, according to William Jon McCann. Here is a discussion of this : https://wiki.ubuntu.com/GnomePowerManagerInactiveSleep 3) all media players should be stopped when ekiga is in a call ; I reported this after reading some blog posts : http://blog.eikke.com/index.php/ikke/2006/04/11/common_interfaces http://blog.eikke.com/index.php/ikke/2006/04/12/first_cdis_proof_of_concept http://blog.eikke.com/index.php/ikke/2006/04/18/more_cdis_spam http://blog.eikke.com/index.php/ikke/2006/04/19/new_prototype I'll also have to check that in all thoses cases, the Inhibit command is something like inhibited++, and ReActivate is like inhibited--; if (inhibited == 0) really_reactivate () ; it would be bad if two programs where inhibiting, and the first to ReActivate where really reactivating ;-) PS: ubuntu's wiki seems down at the moment
*** Bug 330237 has been marked as a duplicate of this bug. ***
*** Bug 338131 has been marked as a duplicate of this bug. ***
*** Bug 338450 has been marked as a duplicate of this bug. ***
Hi, I'm glad that these issues will be fixed, but for the record I would like to repeat that I am against inhibiting the screensaver for an audio only call. The advantage is obvious; a huge cut in power consumption and longer that I can talk before my battery cuts out. There is also the screen burn that screensavers were designed to prevent. The point is that when one is in a voice call, they are not using the screen. If they don't see any benefit in having a screensaver on the occassions when they are not using their screen, they should turn their screensaver off. If they don't like having having their screensaver lock when the screen goes off, then they need to change that setting. The alternative, inhibiting gnome-power-manager directly, would mean that people's screens turn off after a period of not using the machine, but the machine would never suspend. This would mean that, if you are sitting in front of your machine typing or "using" it, it would not turn off the screen. If you were sitting on the other side of the room talking, the screen would turn off.
The point that had been made is that the screensaver was cpu-hungry and perhaps taking resources away from ekiga. One that I want to make is that if one is in a voice call, the screen is not used, but computer is, so it makes sense for it not to act as if it were on its own.
I was wondering if there wasn't already another software doing the same thing, as having code to study would lead to a faster resolution.
The wiki pages that I linked you to have example code that may help you. If not, I have also used those pages to keep track of all the other projects that are working on the features, so you could find their work. If there is anything that is unclear on our wiki pages, however, or the examples that we have provided are not comprehensive enough, we need to update the examples - so please let us know.
I was more hoping for real code than example code -- in my experience example code never even compiles ;-) The fact that I need to store a cookie is annoying me, to name an issue.
Snark, the gnome-power-manager example code[1] compiles fine - I promise! You'll need to change the PowerManager to ScreenSaver if you are just inhibiting the screensaver. There has also been an asyncronous plugin developed[2] for rythmbox which might be of more interest if you want a non-syncronous solution. The cookie thing is essential. It's a uint32 variable that lets you take more than one inhibit if you want. It actually makes working with multiple inhibits easier than writing lots of global state machines. Stuff like nautilus with a copy dialogue, and a move diaglue open just has to deal with one cookie per dialogue without some master controller required (even tho they are in the same process). And I'm sure adding a 32 bit variable to a gobject is okay with most people. :-) If you have any other concerns, or questions, please email me direct at richard_at_hughsie_dot_com and I can help you some more. Thanks, Richard Hughes (gnome-power-manager maintainer) [1] http://cvs.gnome.org/viewcvs/*checkout*/gnome-power-manager/src/gpm-inhibit-test.c [2] http://bugzilla.gnome.org/attachment.cgi?id=72438&action=view
Thanks for the links -- going asynchronous would rock, indeed. I consider that this cookie is a design issue ; it's not just a problem of putting an int into a GObject : basically it means the burden of knowing who inhibited relies at least partially on ekiga/totem/rhythmbox/listen/etc, which is wrong. If you want just a single example of what can go wrong, imagine buggy_program calls Inhibit and gets its cookie, and later on crashes : ciao, cookie. The gnome-power-manager or the screensaver will be stuck inhibited. So what a inhibit-able program should do is get Inhibit requests, note down who sent them, and add them to the pending inhibit request list ; there would be two way to get out of the list : - the same client uses Uninhibit ; - the client disappears from the DBus. This way, there's no need to trust the other program to send any cookie back.
>If you want just a single example of what can go wrong, imagine buggy_program >calls Inhibit and gets its cookie, and later on crashes : ciao, cookie. The >gnome-power-manager or the screensaver will be stuck inhibited. Nope, both gnome-screensaver and gnome-power-manager already monitor the session bus for name-owner-changed, and if a client disconnects (crashes or exits) without calling uninhibit, then all that processes inhibit requests are removed. Some programs may indeed only use Inhibit, and when they exit everything is cleaned up nicely. The reason for UnInihibit is for applications to specify when policy should be disabled and vice-vesa. Hope that clears stuff up. Richard.
Yes, that clears things up. Sorry not to have answered sooner. I'm digging old bug reports to work on them :-)
*** Bug 559352 has been marked as a duplicate of this bug. ***
Here is an update on the matter : http://blogs.gnome.org/hughsie/2009/01/28/inhibits-and-the-new-world-order/ In particular the Inhibit/Unhinibit methods here : http://svn.gnome.org/viewvc/gnome-session/trunk/gnome-session/org.gnome.SessionManager.xml?view=markup Though I still have to decide what to do with that grrmm... cookie.
Ok, done.