Re: New modules in 2.14

[David Zeuthen <david fubar dk>]

On Thu, 2006-01-19 at 14:19 +0800, James Henstridge wrote:
> Richard Hughes wrote:
> 
> >>Of course, this wonderful system does not exist.  Again,
> >>gnome-power-manager is the best offering we have at this time.
> >>    
> >>
> >
> >Thanks! Making g-p-m very closely tied to other GNOME stuff allows it
> >and other programs to play nice, e.g. g-p-m telling g-s to lock the
> >screen after hibernating, all via a nice DBUS interface. g-s can also
> >use g-p-m to blank the screen using DPMS.
> >  
> >
> This always seemed a bit weird to me.  Is there any reason to choose
> this form of integration.
> 
> Wouldn't it have been better to make gnome-screensaver listen for the
> HAL power management events directly, and lock the screen/throttle the
> screensaver where appropriate?
> 
> Similarly, why does gnome-screensaver need to ask gnome-power-manager to
> power down the screen?  Isn't this a simple X call that it could do itself?

Separation by functionality. So I think gnome-power-manager should
manage the power of the system (includes the display) and
gnome-screensaver should manage putting up a screen savers and locking
the screen. Either should have fall-backs if the other is not available
of course. How each depend on the other seems like an implementation
detail and can probably be changed. Is it interesting?

> I guess the main question is: why would an app use the
> gnome-power-manager interfaces to respond to power management events
> rather than HAL's notifications?

I think this is sorta covered in these mails

 http://lists.freedesktop.org/archives/hal/2006-January/004256.html
 http://lists.freedesktop.org/archives/hal/2006-January/004239.html

Basically preparing the desktop before suspending is

 a) a somewhat complicated process if you want to do it right [1] 
 b) something that varies with the reason for the suspend [2]
 c) notifications / prompts for the user under certain circumstances [3]
 d) something apps may want to stall [4]

There's just a lot of corner cases and I do think these justify g-p-m if
we want the right user experience. All this is about policy and thus
don't belong in HAL. Btw, is it now more clear that we need the policy
piece in the desktop session and not on a system-level?

    David

[1] : you want to prepare apps in the right order, e.g. make gedit save
the document to the networking share on the corporate network *before*
nm-applet tears down the VPN tunnel and the network. HAL provides no
such framework.

[2] : HAL would never know why someone invoked Suspend() or Hibernate().
g-p-m knows as g-p-m is the power manager.

[3] : never prompt/notify on lid close (user won't see it!), but
probably OK to bother the user if the reason for suspend stems from a
press of dedicated sleep button or invoked from the menu option of g-p-m
applet.

[4] : e.g. nautilus wants to stall standby when copying files from
remote sites or n-c-b when burning discs. Otherwise these user-initiated
operations fails. Whether g-p-m honors this depends on why g-p-m wants
to suspend. E.g. common sense would say "don't honor on lid close" [5]
but do honor if g-p-m wants to suspend due to session inactivity.

[5] : then the user just made a mistake and it's too late to prompt him;
he will realize when he opens the laptop.. maybe we can even tell him
that though someone would probably think it would be patronizing to put
up a dialog saying "you just created a another coaster"