Re: gnome-screensaver, new api calls requested :-)

[Richard Hughes <hughsient gmail com>]

On Tue, 2005-11-15 at 14:11 -0500, William Jon McCann wrote:
> Hi Richard,
> 
> I'm going to take this onto the screensaver list.
> 
> Richard Hughes wrote:
> > I come with a request for more new stuff :-)
> > 
> > Some laptops turn off the lcd backlight automatically when you close the
> > lid, and I think about 90% of laptops fall into this category.
> > 
> > The other 10% need some DPMS magic. I've been told the usual way of
> > doing this would be to use "xset dpms force off" when the lid is shut,
> > and "xset dpms force on" when the lid is opened.
> > 
> > Knowing you have full control of DPMS in g-s, I was wondering if you
> > could implement one or two more API calls (sorry!) something like:
> > setDPMSPower (bool state) so instead of calling xset (which is a bit
> > hackish) I could just use a simple DBUS method to do the state change.
> 
> Ah, but *should* we have full control of DPMS in g-s?  I'm not sure.

Just for the user-closes-laptop-lid use case I would say yes.

> Let's look at what we do right now in gnome-screensaver.
> 
> All of the power management stuff is contained in the GSPower class. 
> This is basically a singleton that is used only within the GSMonitor 
> class.  The API for the GSPower class is very simple:

<snip>

> Or at least that is how it is supposed to work.  :)

Cheers for the explanation.

> 
> Does any of that really need to be in gnome-screensaver?  Let's see.
> 
> 1. The UI for power management policy is part of gnome-power-manager. 
> So, it probably makes sense to move these GConf keys to it as well.

The enable dpms one? I must admit, as part of the g-p-m "first boot"
I've got it to unconditionally enable the dpms value in g-s gconf so
that power saving for monitors works by default.

> 2. When the screensaver activates a signal is sent over the session bus. 
>   This signal could be handled by any program that listens for it.  This 
> is inherently a racy thing.  However, the action in response to the 
> signal is to set timers that in most sane cases would not act immediately.
>
> 3. Forcing the screen to be on isn't necessarily a control issue.  If 
> control of the DPMS moved to another application that application could 
> provide an interface for changing the state.
>
> 4. Monitoring the state doesn't require control.  If another application 
> controlled the state then either the state could still be polled as it 
> is now or the other application could emit a signal when the state 
> changes.  Again, this could be racy.  However, we only use this for 
> turning themes off when the screen isn't completely on.  We don't 
> support turning the themes back on when the screen comes back on [1].

Yes, this is a good thing.

> It seems to me that we aren't doing anything in gnome-screensaver that 
> we couldn't do anywhere else.  The reason that the screensaver controls 
> power management is mostly historical - there wasn't a better place for 
> it at the time.

Gotcha. I think people are used to it being part of the screensaver, but
thinking about it, I do see your point.

I think g-s is more ready for inclusion into core gnome, and I think
putting the dpms stuff into g-p-m would make an implicit dep for g-s on
g-p-m. My view at the moment is that it should stay in g-s.

> Now that you have created gnome-power-manager it seems like it might be 
> the right home for this.

Heh. I would be fine with dpms control to move to g-p-m, and to provide
an API for g-s to use (if it needed to?) -- I guess it would make g-s
more of a "gnome screensaver" daemon rather than an "xscreensaver
replacement".

> What do you think?

Sounds like a plan :-)

Richard.