Moving PowerDevil to kdereview

[Sebastian Kügler]

Hi,

On Thursday 04 September 2008 20:28:15 Friedrich W. H. Kossebau wrote:
> Should be solved, than. Perhaps by having such a demon on the systembus (if
> possible), implementing a (to be written) freedesktop spec. Have you looked
> at powersaved and similar? Oh wait, I have powersave running here, and
> there are already two interfaces on the systembus,
> "org.freedesktop.Policy.Power" and "com.novell.powersave".


GNOME's powermanager exposes its interface via D-Bus. There has even been some 
discussion about the interface, though I was under the impression that it had 
died out. In any case, we (Danny, me) did provide some feedback from the KDE 
side, resulting in
http://people.freedesktop.org/~hughsient/temp/dbus-interface.html
That's probably as standardised as you can get nowadays. Now this provides a 
basis to work off from, though you'll probably find yourself missing some 
stuff here and there.

> > I don't have any ideas for
> > this, but I think it's the quirk about all power managers. The good point
> > is that very rarely on laptops we have multiple users logged in at the
> > same time, so this shouldn't be a huge issue.
>
> I fear it is more huge than you wish. Many new home computers are laptops
> nower days (cool and movable). You also would like to manage power on a
> non-laptop computer. And a lot are used as multiuser machines. That is the
> power of Unix, let's not bury it.
>
> E.g. I only own a laptop, and when having visitors who want to share it,
> they get an account of their own due to (my) privacy. And I almost never
> logout, hurra to working suspend and session-switching.

I'm not quite with you here. We should optimize for the common usecase, and 
that's a single user on a laptop machine, that's what the apps' functionality 
is there for.

Sure, you can log in with more than one user, but I don't think it warrants 
the changes by an extra policy layer on top of HAL (which you can set up to 
only allow certain users to suspend a machine, for example). 

From the perspective of someone who has written and maintained a 
powermanagement application over the last years, there were exactly zero 
bugreports that the case you're describing was not supported. In fact, Dario's 
design is already much nicer since it decouples policy (set up through 
profiles) and UI (KCM, plasmoid, KRunner as options).

On the other hand, having an independent daemon running and communicating with 
that would circumvent all the logic and policy that's there in Solid, I'd say 
we lose more there than we can win with covering a very slim usecase.
-- 
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 489 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080904/597c46be/attachment.sig>