[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Qt SVG renderer
From:       Rafael =?iso-8859-15?q?Fern=E1ndez_L=F3pez?= <ereslibre () kde ! org>
Date:       2008-08-04 23:07:15
Message-ID: 200808050107.18090.ereslibre () kde ! org
[Download RAW message or body]


Hi,

> what would be useful is explaining, plainly and openly, *why* this is the
> case, even if the answer comes down to "we simply don't have enough reason
> to justify investing further in this technology" or "it would be too much
> work to do otherwise".

Yes, I agree on this.

> but simply repeating ad nauseum "only support SVG Tiny" is really not
> helpful to getting this conversation to a point where there is mutual
> understanding.

Actually, you can implement special features but still not supporting the SVG 
spec fully. That would mean something like TinySVG + special features 
(masking, filters...).

> personally, i'm interested in seeing things that aren't really part of SVG
> Tiny at all, such as being able to ask "which element is at this point in
> the svg", added to the API. this is an absolute *requirement* for doing
> useful things like SVG based on screen keyboard, and is completely doable
> with the current codebase.
>
> but if there is no appetite to extend QSvgRenderer at all (iow, it's in
> pure maintenance mode) then i probably need to know now so i can plan how
> we will work with or around QSvgRenderer in plasma.

Yes, I actually have thought several times about this. How could the svg 
renderer on webkit help us ? Would be a doable (easy) way of stripping all the 
css + js things, just letting the part that is important for us and 
introducing it into kdelibs ?

Can we rely on a 3rd party library that renders SVG ?


Regards,
Rafael Fernández López.

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]