State of the new SVG-stuff

Andreas Pakulat apaku at gmx.de
Tue Oct 21 13:14:50 BST 2008


On 21.10.08 18:07:56, Vyacheslav Tokarev wrote:
> Hi, Andreas
> 
> First, thanks for your concern.
> 
> When I be at home, I will take a look at those files. But I can say already
> that most of these functions shouldn't be used at all, or at least they will
> never be called at runtime.

Ok. Still there need to be return values in the code to compile it with
MSVC. My problem is that I simply don't know what the right default/dummy
values should be, especially in cases like PassRefPtr<CSSValue> in
SVGStyledElement:307.

I'm wondering wether it makes sense to put Q_ASSERT(false) into all these
functions so we can be sure there's no code trying to call them, even in
the future until somebody actually implements them properly. As someone
apparently has to go through all of those that declare return values, this
wouldn't be much of a problem.

> I did that on purpose of not-changing shared SVG
> code from WebCore as not all of the features are ported and supported by
> khtml yet (I had to violate it sometimes though).

I understand.

> For kde4.2 I plan to add JavaScript bindings, maybe fix some style
> properties like ViewBox, and most probably I won't have time to change SVG
> Dom significantly. So we need to figure out the best way to compile it on
> win32.
>
> Again, in the evening from home, I could tell more on the subject.

Well, currently, unless you want to go through all the .cpp files and
check where functions with commented-out-bodies but return values are and
put a dummy/default return statement into them, the only option seems to be
that we play a bit of ping-pong. I'll send a question regarding a specific
place where I can't find a proper dummy/default value myself, you'll tell
me what to put there and I'll continue compilation until I hit the next
place. Some things I can fix myself, like string/double/... returns as
apparently the return values are not used.

Andreas

-- 
That secret you've been guarding, isn't.




More information about the kfm-devel mailing list