KDE/kdelibs/kdeui/icons

[pinheiro]

A Monday 28 July 2008 16:19:06, Aaron J. Seigo escreveu:
> On Monday 28 July 2008, Dirk Mueller wrote:
> > If the general problem is oxygen specific then we should restrict the
> > hack to oxygen,
>
> oxygen shows the problems, but so will any icon that uses SVG features that
> QSvgRenderer doesn't support. i don't think that many other svg themes have
> overly complex icons, though.

i think the old tango is ok, well mostly ok, but the new one "mango" is has 
complex in the svg trics as oxygen is, It's a bit like this, the icon 
creators use basacly 2 programs to make them inkscape or illustrator.. and we 
use everything we can in order to create the best art our skils premit us to 
have. That inculdes masks cliping BLUR (yes we use alot of blur) multiply 
filters etc etc. 

if you askme reandering svg is not the best idea for icons, im taking about 30 
minutes to render some of them, yaeh some are prety complex.... Also svg is 
not realy scalable (I can debate on this issue alot)  but just check out the 
oxygen svg sources to fnd that most icons have svg version for each size...  
same goes for tango btw.. 



> > or if we need one particular feature (you mention blur filter),
> > then implementing this particular filter should be doable for Qt, even
> > though it only wants to support Tiny.
>
> it's not really so much about only supporting Tiny; it's more that the way
> it parses and then processes the elements makes things like blur nearly
> impossible. it will need some large surgery to get such filters working.
>
> not that it isn't worth it .... it's just finding a way to convince TT that
> it is worth it.
>
> > There is an important difference between not wanting to support the full
> > specification and supporting Tiny+selected things that are needed to make
> > our life easier.
>
> agreed; it does mean making huge changes to QSvgRenderer, though.



-- 

core oxygen icon designer