State of the new SVG-stuff

[Vyacheslav Tokarev]

Hi,

SVGStyledElement:307 should be solved now. "new
CSSPrimitiveValueImpl(0)", could be the "dummy" CSSValue (not only
here), and I put Q_ASSERT(false) there. But actually, it looks like
this method just part of the DOM API (i.e. it is used for JS bindings)
and it's never even called in the sources.

Please check now :)

Thanks,
Vyacheslav

2008/10/21, Andreas Pakulat <apaku at gmx.de>:
> 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.
>