[patch #6286] NSBezierPath encode/decode improperly implemented

[Christopher Wojno]

Follow-up Comment #5, patch #6286 (project gnustep):

Ah, now I see what you were doing. You wanted it to fall through so you
didn't have to write the encode again. That does not work, however, with the
decoder as you saw. The encoder case is correct then. It's still broken
without @encode(enum NSBezierPathElement) however.

Yet another decoding bug:
Curved line point decoding is done incorrectly. According to apple's
documentation, the end point of a curved line is p[2], not p[0]. The control
points take up p[0] and p[1]. See:
http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSBezierPath_Class/index.html#//apple_ref/doc/uid/TP40004008

Is it idiotic? Yes, completely. Would I have done it (with end points moving
around in the array of points) that way? No way.

Change:
[self curveToPoint: pts[0] controlPoint1: pts[1] controlPoint2: pts[2]];

To:
[self curveToPoint: pts[2] controlPoint1: pts[0] controlPoint2: pts[1]];

I'm not sure how you wrote the rest of the class (I'm a bit busy with the end
of the semester), but that is crucial for cross platform compatibility.

Glad this is getting looked at. Thanks Fred.

(file #14509)
    _______________________________________________________

Additional Item Attachment:

File name:
gnustep-gui-nsbezierpath-encode-missing-move-to-fix-and-point-order.patch
Size:3 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/patch/?6286>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/