Smarter Screen saver

[Tristan Wibberley]

Thomas Beckett wrote:
> On 9/21/05, Tristan Wibberley <maihem at maihem.org> wrote:
> 
>>Vincent Trouilliez wrote:
>>
>>>On Tue, 2005-09-20 at 23:04 +0200, Sami Dalouche wrote:
>>>
>>>
>>>>Well, in the case totem crashes, the lock would never been removed, I'm not sure
>>>>this idea is the killer-idea, but there definitely must be a way to accomplish
>>>>this easily..
>>>
>>>
>>>Please forgive my ignorance, but I thought this 'D-bus' messaging system
>>>in Gnome was precisely supposed to serve that kind of purpose : let
>>>programs pass/share messages to other programs ?
>>>
>>>Can't Totem etc, just broadcast a message saying:
>>>
>>>"hi, just in case there is a screensaver out there, I am currently
>>>playing a movie, so please don't trigger the screen saver"
>>
>>I dunno, I think it would be nicer if the screensaver daemon asked the
>>window manager if it was okay, then applications could set an attribute
>>on any and all windows that should keep the screensaver at bay. That way
>>the window manager could keep a count of the number of toplevel windows
>>that were preventing the screensaver, and when the screensaver asks the
>>window manager it gets a zero ("okay to start"), or nonzero ("don't
>>start"). If an application dies or any window closes, the count goes
>>down automatically (from the point of view of the applications).
>>
>>This would need a small extension to the window manager standards, but
>>freedesktop could specify that quite easily, and Ubuntu may be able to
>>add a non-standard attribute in a safe namespace (I don't know how the
>>window manager standards are structured) for programs that ship with it.
>>
>>--
>>Tristan Wibberley
>>
>>Opinions expressed are my own and do not necessarily coincide with those
>>of my employer, etc.
> 
> 
> I think DBus would definately be the best way as it is designed for a
> general purpose essage bus. As i responded yesterday (tothe user
> rather than the list - stupid gmail reply)

I think this mechanism ought to work on older and simpler systems
without relying on dbus. The window manager already has an understanding
of multiple desktops - this would integrate into there just perfectly. I
don't think dbus is the right solution for this. Having the window
manager manage this would be ideal since if the video window is on a
different virtual desktop to the one being displayed, the screensaver
should be able to come up (although I think the screensaver should have
a master volume control too - so in any cases where the user has left
audio blaring anybody that has to share their space with the speakers
can just turn it down).

> 
> But that would require the screensaver to know every proram that is
> used where user inactivity should not trigger the screensaver. A
> better solution would be to have the screensaver listen on the dbus
> for a SCREENSAVER_POSTPONE message, maybe with a time to postpone for
> (playtime of movie etc).The screensaver would then be disabled from
> running for that time or until a SCREENSAVER_RESUME was sent when the
> user stops the film. This would then shift the burden of supporting it
> to the programs that actually want to postpone the screensaver which
> would be much better in my view. Is this viable or is it a bit
> overkill for the screensaver?

I don't see why dbus is more appropriate than the window manager. I
think the window manager would be even more appropriate (what if
xscreensaver isn't running when each application sends its
notification). Having the screensaver notified when it can start is an
interesting idea, it would stop the screensaver from polling for
permission all the time, but is probably not a problem.

> The idea for the postpone time was that if the player did crash before
> the film or whatever you are doing finishes then the resume signal
> would not need to be issued, it would wake itself up.

I think the window manager can handle this even better. Then its only
your window manager that must not crash - which is a much safer bet than
relying on xscreensaver.

I think dbus is appropriate for all system level notification, but
notifications should also integrate into the classical mechanisms too.
Especially in the case of the interaction between X server, WM, and X
clients. It keeps things clean and simple - X apps just have to do more
X-ish stuff, which makes sense.

-- 
Tristan Wibberley

Opinions expressed are my own and do not necessarily coincide with those
of my employer, etc.