We should kill nsSVGValue and nsISVGValue. This shouldn't take long now, so I'll knock up a patch for this later this evening.
Created attachment 563550 [details] [diff] [review] patch
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.
(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.)
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?
(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.
OK, how about raising a follow up then to see if the module owner wants it done or not.
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?
(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.
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.
Created attachment 563589 [details] [diff] [review] patch with enum tweaked Good enough compromize for you, longsonr?
Comment on attachment 563589 [details] [diff] [review] patch with enum tweaked You had an r+ last but here's another anyway :-)
Thanks, just checking! :-) Pushed https://hg.mozilla.org/integration/mozilla-inbound/rev/d74000e4f76a