battery monitor plasmoid changes

Aaron J. Seigo aseigo at kde.org
Mon Feb 16 19:14:01 CET 2009


On Thursday 12 February 2009, Sebastian Kügler wrote:
> > To accomplish this I added another layer to the svgz icon as well as a
> > configuration option to allow the user to choose the old style display
> > (4 separate blocks) or my continuous mode display.
>
> I personally think it doesn't need its own config option, instead I'd go
> for just making it default. Thing is that it's an artwork issue, which is
> Nuno's domain.

i personally find discreet easier to read, though the art could be done 
differently. the trick is to have some visible demarcations, like the lines on 
a measuring cup. fading out the individual "slices" is a really nice touch 
imho.

the big issue imho with a continuous mode is that we will still want some 
discreet-style behaviour, such as e.g. being able to change the colour as it 
gets close to empty.

that said, it should be possible to do *either* with an appropriate svg. 
currently, there are only 5 states allowed for in the svg, and that could 
probably be improved. but i see no reason why the current svg couldn't even be 
used to do a continuous meter. i suppose the real issue is the granularity of 
the steps rather than continuous-versus-discreet, however. 

after all, "continuous" just means "the discreet step is numberOfPixels/100" 
;)

how to achieve that graphically with elegance is the question.

btw, in a discreet model increasing the # of steps can be done with backwards 
compat / without adding to the work of artists who don't care by using the 
element nearest to the %. so if it went by 5% steps (which should be plenty?) 
one could check for, e.g., 85% and if that doesn't exist look for 80% when the 
battery is 83% charged.

anyways, i haven't seen the patch so i have no idea what the patch actually 
does.

> Basically, additionally to your issue (which I think is a valid point,
> especially interesting for larger / higher dpi representations of the
> applet Nuno asked me if I could do some stepping, so we don't get the SVG
> rendered at for example 27 pixels which *will* produce bad results. Instead
> the applet should, based on its size be rendered at 16, 22, 32 and 48
> pixels. Starting with that size, it could probably just scale up.

so it will float in the middle of a 30 px layout, with 4 px above and below? 
that's going to look highly questionable. perhaps you mean that the meter 
inside the battery will only get rendered to those sizes? that could make 
sense.

> > I tried to adhere to the kde coding style guidelines and what the
> > program already had.
>
> The patch looks technically good.

which patch is this?

and yes, a config option would be ridiculous for this.

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

KDE core developer sponsored by Qt Software

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090216/57b988bd/attachment.sig 


More information about the Plasma-devel mailing list