Re: New modules in 2.14

[James Henstridge <james jamesh id au>]

David Zeuthen wrote:

>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 thing I found weird was that g-p-m was signalling
gnome-screensaver directly rather than gnome-screensaver listening to a
general power management event broadcast (which could either be from HAL
or g-p-m).

>>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?
>  
>
Okay, it does sound like some per-user program is necessary to handle
these parts of the power management system.  The fact that the g-p-m
contains special knowledge of gnome-screensaver still seems a weird way
of doing things, and won't scale as more apps become aware of power
management events.

As an example, say the Totem developers decide it would be nice to
disable the video pipeline when the laptop's lid is closed to conserve
power.  It would be much easier to do this by making totem listen for a
broadcast, rather than modifying g-p-m to send a special notification to
Totem.

James.