Re: Moving DPMS to gnome-power-manager



On Thu, 2006-01-05 at 15:38 -0500, William Jon McCann wrote:
> Richard Hughes wrote:
> > On Thu, 2006-01-05 at 12:27 -0500, William Jon McCann wrote:
> >>I'm thinking that we make the following changes:
> >>
> >>1. Move the GConf keys and policy management to gnome-power-manager
> > 
> > Sure, good for me. I guess you mean the dpms_* keys currently in g-s.
> 
> Yup.

Might be best to put these in /dpms/ as I currently have a little tree
going on with the other stuff.

> > So, we need a DPMS API for g-p-m:
> > 
> > typedef enum {
> >         POWER_MODE_ON,
> >         POWER_MODE_STANDBY,
> >         POWER_MODE_SUSPEND,
> >         POWER_MODE_OFF
> > } PowerMode;
> > 
> > void DpmsPowerSet (int PowerMode)
> > int DpmsPowerGet (void)
> > 
> > Or should we break out these individually like:
> > 
> > void DpmsPowerSetModeOn (bool);
> > bool DpmsPowerGetModeOn (void);
> > 
> > And presumably emit:
> > 
> > DbusStateChanged
> 
> I'm not a D-Bus expert/insider so there may be a better convention, but 
> how about:
> 
> Methods:
> void  setDpmsMode (const char *mode_string)
> char *getDpmsMode (void)

Yes you are right, probably strings are better.

> Signals:
> DpmsModeChanged (const char *mode_string)
> 
> where mode_string is one of: "on", "standby", "suspend", "off".
> 
> > Incidentally, what is the practical difference between
> > GS_POWER_MODE_STANDBY and GS_POWER_MODE_SUSPEND? 
> 
> This says there is a difference:
> http://en.wikipedia.org/wiki/VESA_Display_Power_Management_Signaling
> 
> In practice I'm not sure most hardware follows that but we should 
> probably respect the standard.

Sure, okay -- thanks for the link.

> > Sure -- do you feel confident hacking on the g-p-m codebase, or do you
> > want me to implement this? I definitely need help with the API design.
> 
> I think we can copy and paste a good deal of this.  I'll take a stab at it.

Sure -- you use gobject stuff I've noticed -- I tend to stick to the raw
code as the methods in g-p-m at the moment are trivial. Either is good
for me, but I would probably prefer the simple code.

Richard.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]