[Panel-devel] battery applet

[Aaron J. Seigo]

On Thursday 28 June 2007, Sebastian Kügler wrote:
> On Thursday 28 June 2007 13:14:45 Kevin Ottens wrote:
> > Le jeudi 28 juin 2007, Sebastian Kügler a écrit :
> > > As some of you already have seen, I've put a battery applet into
> > > playground. Some people have already worked a bit with the code. The
> > > catch is that I'm new to C++, so there are probably dumb things in
> > > there.
> > >
> > > So if someone wants to look through the code, I'd appreciate comment.
> > > But by all means, don't let me steal your valuable time.
> > >
> > > The code is in
> > > http://websvn.kde.org/trunk/playground/base/plasma/applet/battery
> > > A screenshot is at http://vizzzion.org/images/blog/battery-plasmoid.png
> > >
> > > Christopher Blauvelt has adapted the applet for use with the
> > > solidengine, so the battery dataengine might soon go away.
> >
> > 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.
>
> > 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 think it makes sense to have separate engines; it'll make it easier and more 
obvious for people writing plasmoids.

> 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).

powermanagement makes more sense to me. please feel free to make this change.

> 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

there's a few ways i can think of addressing it:

- summing up the current status and not caring about the details that the 
totals may come from multiple batteries; one of the data entries could be 
Number of Batteries and leave it at that.

- provide a data source for each battery. then the question becomes how to 
reference the batteries as a tree would be the most "natural" structure here, 
though i'm trying pretty hard to avoid trees in engines as it complicates 
things on a few fronts, not least of which is for plasmoid authors (and i'm 
striving to keep those bars low, low, low)

- a combination of the two above. so there is a summary source and a source 
for each battery. the summary source could provide a list of the battery 
names, making it easy to discover what the source names for the other 
batteries are.

btw, you probably want to reimplement QStringList sources() const; to return a 
list containing "Battery", "AC Adapter", and "Sleepstates" since these are 
essentially "virtual" sources rather than sources that are populated due to 
configuration. if the multiple battery entries approach is taken, then 
sources() should also return those if they are already available but not 
otherwise since those would be populated on demand.

i'll try and make the different "kinds" of sources clear in an upcoming 
techbase tutorial.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20070628/58103009/attachment.pgp