690486 - Kill nsISVGValue, nsSVGValue, nsISVGValueObserver, nsISVGValueUtils and nsSVGStringProxyValue

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Jonathan Watt [:jwatt]]

We should kill nsSVGValue and nsISVGValue. This shouldn't take long now, so I'll knock up a patch for this later this evening.

Comment 1

[Jonathan Watt [:jwatt]]

Attachment: patch

Comment 2

[Jonathan Watt [:jwatt]]

The do_GetWeakReference calls in SVGLengthList.h (and the other list types) now depend on nsGenericElement implementing nsISupportsWeakReference, although nsGenericElement implements that interface using a tearoff (called nsNodeSupportsWeakRefTearoff). That means we'll be allocating a tearoff when animating list type attributes, but that seems okay.

Comment 3

[Jonathan Watt [:jwatt]]

(For the record, XUL templates still work with the new world C++ attribute class types. See the still working http://www.croczilla.com/bits_and_pieces/svg/samples/xulsvg1/xulsvg1.xul (for which you'll need https://addons.mozilla.org/en-US/firefox/addon/remote-xul-manager/ installed) for example.)

Comment 4

[Robert Longson [:longsonr]]

Is Brian going to want to put any of this back in order to implement bug 629200? I suspect the answer is no based on the final comment in that bug.

As far as the change itself is concerned all I have is this...

>     eColor =        0x07, // 0111
>     eEnum =         0x0B, // 1011  This should eventually die
>     ePercent =      0x0F, // 1111
>     // Values below here won't matter, they'll be always stored in the 'misc'
>     // struct.
>     eCSSStyleRule = 0x10,
>     eAtomArray =    0x11 
>-    ,eSVGValue =    0x12
>     ,eDoubleValue  = 0x13
>     ,eIntMarginValue = 0x14

Can you should shuffle up the remainder and while you're there make the commas nice please?

Comment 5

[Jonathan Watt [:jwatt]]

(In reply to Robert Longson from comment #4)
> Can you should shuffle up the remainder and while you're there make the
> commas nice please?

I don't really want to unnecessarily mess with blame in someone else's module.

Comment 6

[Robert Longson [:longsonr]]

OK, how about raising a follow up then to see if the module owner wants it done or not.

Comment 7

[Jonathan Watt [:jwatt]]

Sicking, regarding comment 4, do you think I should make any of the suggested changes to the enumerations? Or perhaps at least renumber eDoubleValue and eIntMarginValue so there's no gap in the numbering?

Comment 8

[Brian Birtles (:birtles, Feb 26~ parental leave)]

(In reply to Robert Longson from comment #4)
> Is Brian going to want to put any of this back in order to implement bug
> 629200? I suspect the answer is no based on the final comment in that bug.

That's right. The current approach I'm using it to add a number of new types in place of eSVGValue so it can definitely disappear as far as I'm concerned. Thanks for checking though.

Bug 629200 is coming along pretty well but I'll be away for about the next month so I'll hopefully post a few wip patches today.

Comment 9

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Please do shuffle things up or rearrange them as much as needed to keep the code clean and gap-less.

Don't change the values *above* the "Values below here..." comment unless you understand how they interact with the types.

Comment 10

[Jonathan Watt [:jwatt]]

Attachment: patch with enum tweaked

Good enough compromize for you, longsonr?

Comment 11

[Robert Longson [:longsonr]]

Comment on attachment 563589 [details] [diff] [review]
patch with enum tweaked

You had an r+ last but here's another anyway :-)

Comment 12

[Jonathan Watt [:jwatt]]

Thanks, just checking! :-)

Pushed https://hg.mozilla.org/integration/mozilla-inbound/rev/d74000e4f76a

Comment 13

[(no longer active)]

https://hg.mozilla.org/mozilla-central/rev/d74000e4f76a