I spend some time to find out why the NSView_bounds_scale.m test is
failing and now I am pretty sure I have the solution, although I don't
like it.
The problem here is the boundsRotation. Apple seems to have a very
specific concept here. The value returned by that method (and used
internally by methods like setBoundsRotation:) isn't what you would
expect. I think they store this value directly for the NSView and adjust
it only from the rotation methods. That is, this value has nothing to do
with the actual rotation value of the current bounds transformation
matrix, as we implemented it in GNUstep. The important difference is
when you combine a scale operation with a rotation. Independent of the
order of these operations Apple comes up with the same rotation value,
whereas GNUstep will end up with different values.
As there is no use in saying that our results are mathematically
correct, I suggest that we move over to the Apple way of doing things
and start storing the rotation in the NSView. This saves us one
expensive call to atan2() as well.
The same change may also be needed for the frame rotation, but I will
have to write more test code to verify this.
Fred
_______________________________________________
Gnustep-dev mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
