Re: Patch to fix view rotation and hitTest:

[Banlu Kemiyatorn]

On Sun, 13 Mar 2005 17:40:40 +0100, Fred Kiefer <address@hidden> wrote:
> I looked at that patch, but I am surely no expert in that area. What I
> did not quite get is the intention of this patch. It seems to be fine,
> as far as I can tell and in many cases we save us the creation of yet
> another matrix. Is this the whole point behind the patch?

The problem that this patch is trying to solve is, in old behavior when you
set the frame origin of a frame that already rotated, the new coordinate
will apply on the current framematrix and get a wrong origin instead of
one that should rely on super view's (since the frame matrix was rotated)
so I tried to seperate the translation from the rotation.

> NSAffineTransform is in many cases the class we create the most objects.
> (only notifications seem to be worse) So saving some should be
> worthwhile, but somehow I can only see this as a half hearted attempt on

eliminating _frameMatrix was just a free plus.

> this. We really should try to find out where all this matrixes are
> coming from.

May be all these _matrixTo/FromWindow, bounds matrix and frame matrix per view?
(I am wondering if it is better if we can only keep the struct and process
the matrix struct with C functions internally.) I think these matrics
(especially bounds)
can also be eliminated using the same approach.

> But then, I may have totally missed the point behind the patch.

This patch try to solve the problem when you set origin of a rotated frame
and to correct hitTest problem that the point can fall-off the frame if
the view is rotated, (checking subview's _frame won't know if subview
is rotated or not, the given aPoint is in superview's coordinate).
 
> > BTW. I don't like that we load a few methods to NSAffineTransform.
> > Is it a bad idea to subclass it for NSView?
> 
> We could get rid of some of them, because they are no longer used, or
> could be replaced easyly. But where do you see the problem? This is
> internal to the GUI framework, any additional categories shouldn't do
> much harm.

May be when user want to have their own category that have the same name.
I don't know who would actually want this though. But it just looks a little bit
cleaner to me :)

-- 
    _----_     Banlu Kemiyatorn
  /   /\   \   Free Software Yogi
 |   /  \   |  -_-~-_-~-_-~-_-~-_-~-_-~-_-~-_
 |  /----\  |  QSTORAD, Qing  Shan Tian Xia
  \/      \/   136 Nivesana 7, Jangwattana 14
   QingShan    Laksi, Bangkok, Thailand 10210