Closed Bug 690486 Opened 8 years ago Closed 8 years ago
ISVGValue, ns SVGValue, ns ISVGValue Observer, ns ISVGValue Utils and ns SVGString Proxy Value
We should kill nsSVGValue and nsISVGValue. This shouldn't take long now, so I'll knock up a patch for this later this evening.
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?
Attachment #563550 - Flags: review?(longsonr) → review+
(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.
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 :-)
Attachment #563589 - Flags: review?(longsonr) → review+
Thanks, just checking! :-) Pushed https://hg.mozilla.org/integration/mozilla-inbound/rev/d74000e4f76a
Summary: Kill nsSVGValue and nsISVGValue → Kill nsISVGValue, nsSVGValue, nsISVGValueObserver, nsISVGValueUtils and nsSVGStringProxyValue
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla10
You need to log in before you can comment on or make changes to this bug.