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/ _______________________________________________ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
