[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: [Panel-devel] battery applet
From:       Kevin Ottens <ervin () kde ! org>
Date:       2007-06-28 11:50:18
Message-ID: 200706281350.22975.ervin () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Le jeudi 28 juin 2007, Sebastian Kügler a écrit :
> On Thursday 28 June 2007 13:14:45 Kevin Ottens wrote:
> > Well, you probably want more than simply reporting one battery level,
> > don't you?
>
> Yes, but for a prototype, I think this is quite OK.

Sure, but I guess it won't stay a prototype for long. ;-)

> > Actually, you probably want to report the overall battery level...
> > Reporting only _one_ battery level is not enough for some systems. In
> > fact, that would be nice to have a "powermanagement" dataengine (I don't
> > like the name battery), and the applet could use this one or the
> > solidengine to report battery level... Depending on the engine it uses
> > you'd focus on one battery, or the overall state of the system.
>
> That's right, whether or not we want a separate dataengine for that, I
> don't know.

I'd say yes, since the logic needs to be somewhere and I don't see the 
current "solidengine" to be the right place for this.

> It probably depends on how much code would be duplicated, and 
> how much overhead one or the other case causes. (Since it's mostly
> SIGNAL-based, I don't think that'd be a lot though.) I'd not have a problem
> with deleting the battery dataengine (did indeed ponder renaming it to
> something
> like "powermanagement engine", but I'd like to discuss this with others
> first).

Sure.

> Regarding different batteries, combined states and the like: I don't know
> how to solve this problem at this layer in the best possible way. Having a
> second battery (which I don't have) would probably make it easier to futz
> with this.

It's not the right layer IMO. And actually that's why we have 
Solid::Control::PowerManager, it is responsible for doing the combined 
states, etc. Not sure the algorithms used are optimal though, could probably 
be improved.

Regards.
-- 
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."

[Attachment #5 (application/pgp-signature)]

_______________________________________________
Panel-devel mailing list
Panel-devel@kde.org
https://mail.kde.org/mailman/listinfo/panel-devel


[prev in list] [next in list] [prev in thread] [next in thread]