org.freedesktop.PowerManagement

[Holger Macht]

On Thu 22. Mar - 13:37:12, Richard Hughes wrote:
[...]
> >Just curious why we need this Reboot and Shutdown related methods in this
> >API at all.
> >
> >Yes, generally they're somehow related to Suspend and Hibernate, but isn't
> >this something that should be available regardless of power management?
> >I'm not quite sure how this is handled in KDE and GNOME these days. The
> >desktop has to provide these methods with no regard on any power
> >management applications. If there's no gnome power manager or kpowersave,
> >you still want the user to shutdown or reboot, no? Shouldn't they be in
> >the desktop base somewhere?
> 
> I do see your argument, but I think they "fit" here. Say we just have
> a distro update program that just puts up a dialogue "Updates
> installed, restart?" then this simple program can fire a method off to
> o.f.pm, which in turn can talk with the desktop environment and close
> down applications and save state. Then the session pm service can call
> o.f.Hal to actually do the restart.
> 
> This way we can integrate a common "restart" API call on top of very
> different session saving technologies, e.g. what GNOME and KDE use
> now.

Ok, but than all the desktop people have to get involved and have to agree
on this. Because once this is defined, they have to provide the interface
functionality somewhere else if g-p-m or kpowersave are not running. On
every system, you always need a org.freedesktop.PowerManagement.Reboot, no
matter what.

[...]
> >> boolean GetLowPowerMode (void)
> >
> >This method, is it the same as the one exported by HAL? I mean, the one
> >that comes from pm-utils?
> 
> No, it's a user preference version of it. Imagine this method
> returning false when we are on AC, or > 50% on battery, but returning
> true when <50% of battery. That point where the system is "low" is
> probably best defined in the session, so KDE can make it configurable,
> and gnome can hardcode something semi-sane. ;-)

Sounds sane.

[...]
> >> string GetDescription (void)
> >
> >Can you give an example of what this method might return?
> 
> Well, it depends on the user preferences, the desktop envirnment and the 
> locale.
> 
> Typically it would be something like:
> 
> "Computer is running on battery power\n
> 1 hour 17 minutes remaining"
> 
> But this is obviously down to the user preference settings, and what
> the DE want's to show the user. For OLPC it might just be something
> like "Battery 50%", but it's something that any random application can
> use as a general description of the power state of the machine.
> 
> This is not critical to the spec, and I don't mind punting it for now
> if there is not agreement.

All the information in this description should be provided by the
interface somehow IMHO. Taking your example, other applications should be
able to query the interface if the system is running on battery power and
how many minutes are remaining. Then they are able to build up the
description on their own. If it's a user preference, they can never be
sure that the information presented is not misplaced in their current
context.

> >> string GetIcon (void)
> >
> >Can you elaborate a bit on this please? It still seems to be misplaced to
> >me. Shouldn't those icons be defined by the theme? And shouldn't one be
> >able to query its details anyway?
> 
> Sure, again see above. It's just a random icon we can present to the
> user, which probably should have it's names defined in the icon naming
> specification or something.
> 
> At the moment, I've got this returning a string like
> "gpm-charging-080" which is a g-p-m specific icon.

>From my understanding, themeing means that you have a iconset for every
arbitrary situation. So there's an icon for 'charging', one for
'discharging' and one for 'low power' applications can chose of.

I currently just don't see a situation where this does not work and one
needs an additional information source.

> Again, we can punt this for now if you want; there are much more
> important things to decide on.

Yes, I would rather put it in the queue for now.

Regards,
	Holger