Battery applet and KIcon

[Marco Martin]

On Sunday 14 February 2010, Aaron J. Seigo wrote:
> On February 14, 2010, Marco Martin wrote:
> > On Sunday 14 February 2010, Aaron J. Seigo wrote:
> > > On February 14, 2010, Riccardo Iaconelli wrote:
> > > > Hello,
> > > > to follow up on a message i sent some time ago, I started to convert
> > > > the battery applet to make it use KIcon. =)
> > > 
> > > a) use reviewboard
> > > 
> > > b) since when have we abandoned scalable interfaces? ("nobody uses it
> > > larger than 64 pixels, and we will generate a 256px icon"; seriously?)
> > > 
> > > c) how does this allow one to ensure the battery matches the desktop
> > > theme?
> > > 
> > > d) if this is such a brilliant idea, why can't the pixmaps be put into
> > > the SVG file along with the freely scalable version?
> > 
> > I see the problems of both sides, because, with an icon
> > would be hard to change it depending on plasma theme
> > limited only for some sizes
> > 
> > however:
> > it is absolutely true that a svg rendered at a random size can look
> > really bad when is not aligned at the pixel grid
> 
> this is a general problem, we should investigate a general solution.
> 
> > or it too detailed (or not
> > enough) for the rendered size (in the end this is why true type fonts
> > have that scary hinting language)
> 
> i don't thin we need a scary language, but some simple hints might do.

for a really generic thing, i fear something would be needed at the level of 
QSvg.
and always will have some approximate results.
QSvg should do something like:
-when rendering a shape, always adjust its bounding rect to the pixel grid.
-if it has a border adjust the bounding rect of the border instead
would probably yeld slightly better, even if not perfect results.

but Plasma::Svg is probably a farr too high level for that ;)

from our end, lookin if there is an "optimized" version for a certain size is 
the better we can do
also because this is a problem that is really visible at small sizes (still 
present at big sizes, but less noticeale)

> > so what i propose is the following:
> > use the svg for the battery as now, -but-
> > if we are rendering at a certain size, and the element in the svg we want
> > to render is "battery" search another one with the proper prefix, for
> > instance "22-battery" before. it can be a svg, an embedded pixmap
> > whatever (we should really understand what is the more efficient between
> > the two probably) if is found paint that, otherwise paint  the fallback
> > general one.
> 
> this sounds like a good start to a general solution we could apply
> elsewhere. i'd like to put this on the table for tokamak 4 where we can
> properly discuss it and experiment with a number of people with the
> various expertise needed around one or two screens.

i think we could introduce that kind of fallback directly into Svg, maybe with 
an overload in paint() and pixmap() (maybe it could even be nice to introduce 
support for a QStyleOption, hmm)

-- 
Marco Martin