Re: xscreensaver, any plan do drop it !!

[David Zeuthen <david fubar dk>]

Hi,

On Fri, 2005-07-08 at 10:14 -0400, William Jon McCann wrote:
> Hi David,
> 
> David Zeuthen wrote:
> > 1. How do see this being integrated with power management solutions like
> > e.g. the existing gnome-power project and some of the ideas that were
> > discussed at GUADEC [1]? 
> 
> This is certainly the next step.  Up until now I have been concentrating 
> mostly on feature parity with xscreensaver.
> 
> There is some overlap between gnome-power, gnome-screensaver, gdm, and 
> the fast-user-switch applet.  We need to make sure they are all in 
> concert.  Perhaps a new gnome.org mail list is in order on which to 
> discuss these issues (gnome-power-list)?

Good question. I guess utopia-list gnome org could work for this but I
don't know really.

> A few initial thoughts.  We need to make a distinction between system 
> idle and session idle.  We need to make screen power management work 
> sensibly with user switching where the session doesn't own the physical 
> monitor.  In that sense, gnome-screensaver and xscreensaver get it wrong 
> I think.  

There's a bunch of issues we need to carefully look at.

My take on this is that we need some facility in the desktop session to
query for whether we're currently displayed on a physical monitor (e.g.
console).

It's my view that if we're not on a physical monitor (e.g. either a
remote session or hidden via f-u-s) we're not allowed to enforce any
policy that affects the system on which the session is launched. What
does this mean? It means that we shouldn't mount storage volumes, put
the system or monitor to low-power mode (e.g. system suspend), we
shouldn't have access to audio, cameras and webcams and so forth. Thus,
we need to hack up e.g. gnome-volume-manager and gnome-power to
understand this.

Conversely, a desktop session on a physical monitor attached to the
system should indeed enforce these policies.

Finally, desktop sessions need to handle transitions, e.g. give up
ownership of e.g. audio devices and webcams when e.g. being put in the
background using f-u-s.

There's also the (somewhat uninteresting) question of what to do when
there are no desktop sessions, e.g. what piece gets to enforce the
policy that the system should be put into low-power mode (and where does
it read settings from?)? I'm mostly of the opinion that we launch the
policy enforcing daemons (e.g. gnome-volume-manager, gnome-power) with a
--no-display option as user e.g. nobody (which makes them read default
settings from gconf) from gdm when there are no sessions. This is also
somewhat OS/distro specific.

Ideally we would have a per-session daemon with a D-BUS interface with
method bool isOnConsole() and signal onConsoleChange(bool isOnConsole)
that our policy-enforcing bits can listen on. We need some guards /
check points to prevent race conditions when switching sessions (need to
ensure session A gives up all devices before session B attempts to
acquire them) though so my guess is that the interface would need to be
slightly more complicated.

Where would be the best place for this interface to live? My thinking
right now is gnome-screensaver. What do you think?

> How do HAL and power-manager handle the situation where more 
> than one user is logged in to the console via gdmflexiserver?

hal isn't really concerned with the desktop session and only reports
events about the local system and attached devices. I think that
gnome-power right now ignores the issue of multiple sessions all
together.

> We also need to turn off screensaver themes when the system is running 
> on battery power.
> 
>  > 2. How does this integrate with fast-user switching?
> 
> I have a copy of the fast-user-switch-applet code in gnome-screensaver. 
>   Currently, it isn't being used up to it's potential.  It could be used 
> to create a list of current users right in the unlock dialog.
> 
> At the moment, if you don't have the fast-user-switch-applet on your 
> panel then gnome-screensaver's user switching isn't very useful.  There 
> shouldn't be any "dead-ends".
> 
> There is a lot to discuss :)

Certainly! I hope my thoughts above are clear enough and I'm not over
complicating things :-)

Cheers,
David