Re: [gnome-love] Re: GNOME Screensaver Frontend [Backend]

[Martin Pool <mbp samba org>]

On 23 Nov 2003, "Curtis C. Hovey" <sinzui cox net> wrote:
> On Sun, 2003-11-23 at 20:45, Jeff Waugh wrote:
> > Hi all,
> > 
> > Something that has come up many times, but probably not fleshed out enough
> > for pimping to gnome-love and new contributors is a new GNOME Screensaver
> > frontend. Despite previous attempts, it seems that 'fixing' GNOME support in
> > xscreensaver itself is pretty pointless, but the hacks 'protocol/standard'
> > is worth supporting, so...
> > 
> >   * New GNOME daemon and frontend to launch and configure xscreensaver hacks
> >     (it could be in gnome-settings-daemon or something like that, but that's
> >     an implementation detail).
> > 
> >   * Provides some detail to the rest of the system about idle time (via X
> >     and D-BUS, whatever standards are in place). Curtis had some points
> >     about this, which I'll leave to him.
> 
> There are a number of GNOME applications that monitor idle/activity, and
> each has its own code to do it: xsceensaver + xlock, DrWright,
> medusa-indexd, power management.  I think some daemon is needed (maybe
> gnome-settings-daemon) to monitor the hardware and report the status to
> subscribing applications.  

In fact I would like to distinguish a few possible states:

  user is actively using the machine (conversely; has not used the
  mouse or keyboard for n seconds)

  user marks themselves as away

  screen is blanked or locked
  
  screen is suspended by DPMS

Having a common framework for this would not only remove some
duplication and inconsistency but might also enable interesting new
features.

For example, a few different applications remember security
information for the user (ssh-agent, sylpheed, evolution, mozilla,
mutt, ...)  I might like to have them delete my authentication tokens
when I'm away from the machine or when the screensaver activates.  Not
all of them are GNOME or even X apps, but if there was a command-line
interface it could be done.

You might extend the concept of "away" in a similar way to that used
by jabber, so that the user can distinguish "busy", "briefly away",
"extended away", etc.  The details of this may vary between
applications.  But perhaps there might be a common interest in the
user being able to say, across the whole desktop, "don't interrupt
me".

> The API may need conflict resolution because an indexer cannot run
> if the HD is powered down.  The API may also provide time-based
> actions like cron for users to schedule tools to run.

I don't think GNOME needs to get directly involved in reporting
hardware power state.

Debian's anacron package handles some of these items by calling out to
/usr/bin/on_ac_power and deferring execution if that is not true.

-- 
Martin 
                               linux.conf.au -- Adelaide, January 2004