[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Patch to fix view rotation and hitTest:
From: |
Banlu Kemiyatorn |
Subject: |
Re: Patch to fix view rotation and hitTest: |
Date: |
Mon, 14 Mar 2005 00:27:54 +0700 |
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