More KDE-Edu icons needed

[rwlbuis at xs4all.nl]

Hi,

> On Tuesday 06 January 2004 20:56, Ante Wessels wrote:
>> On Domingo 04 Enero 2004 22:34, Anne-Marie Mahfouf wrote:
>> > Hi!
>> >
>> > In the kdeedu module, some icons are not totally Ok so we need to
>> improve
>> > them.
>> > Having a svg image made for each creation of 128, 48, 32 etc sizes
>> would
>> > be nice.  Especially 128x128 is missing for some apps and OS X needs
>> > that.
>>
>> If there are SVGs the rendering should be possible automatically, not?
>
> I've also been interested in this. Nevertheless it is a /highly/ wanted
> feature. It would reduce *a lot* of work, close about 30(?) bug reports
> and
> all the latent ones, open up graphic development, save disc space as well
> as
> a more functionality for the user.

Are you sure it will close that many bug reports, all unique bugs? And
what are they like?

> The drawbacks is that the current ksvg implementation is way too slow to
> make
> it practical(that is what I've heard) but that will perhaps change. And

Right, though we call it svg icon engine, which can be found in
kdelibs/kdecore/svgicons. I heard the same, though I didnt do any tests.

> then
> the icon loader should be prepared.. Worth mentioning on the subject;
> QuakeForge(open source version of quake1) started gzip'ing their game data
> and in the over all picture the loading went much faster because time
> spent
> on decompression was multiple fold won back on the the short read times
> required from (hard) disc.

Right, all crystal SVGs seems to be in .svgz format, which is svg + gzip.

> Another reason to prefer png's is that they look better in low
> resolutions(also what I've heard).

Perhaps 16x16, 22x22 and 32x32 could be pngs, bigger all generated at
runtime from svgs... I dont know if there is some exact boundary size
below which png is better and above which svg is good enough though...

> Perhaps the ksvg-team can give an update on the issue(CC'ing around).

Well IMHO the svg icon engine should be rewritten, and I already did some
experimental code for that. That code was tested standalone though, I
havent tried to make kiconloader use it. We'll probably continue
experimenting, seeing whether the engine can be efficient enough, but this
wont be ready for 3.2, so probably 3.3...
Cheers,

Rob.