Matt Rice wrote:
--- Enrico Sersale <[EMAIL PROTECTED]> wrote:
Just to be more precise :) ... I'm not referring to
this; I've fixed it implementing -copyWithZone: in
my cell class when I've seen that gworkspace
segfaults trying to release an ivar of this class.
The real problem is that it is not possible anymore
to start a drag from a cell (this is visible in
GNUMail, too). Making -startTrackingAt:inView: to
return NO in the cell class fixes this problem too,
but I think that there is something wrong in
-mouseDown: because, before theese changes, both the
apps worked well.
indeed I don't think that should be required either.
(though looking at the docs i noticed that
-startTrackingAt:inView:... returns NO if the view
doesn't send actions on dragging or periodic events
it isn't clear whether this affects the return value
of trackMouse:inRect:...
anyhow a little testing shows you are correct.
this changes the behaviour of trackMouse:inRect:..
slightly to cope with an event that happened in the pa
in a dragging source table view
trackMouse:mouseDownEvent will be sent after the mouse
has gone up (when it is clear that no dragging has
been started).. though this severely limits the cells
which will work with one
sure isn't pretty though, that's probably fixable..
This is a rather huge patch, could you please describe in more detail,
what you are aiming at with it? What did you test and how does MacOSX
differ from the current GNUstep behaviour?
Most of what changed looks like just a reformatting, which should be
harmless, but this makes it hard to see the actual change itself. Would
it be possible to provide a different patch, which tries to keep the old
formatting (perhaps by using some dummy {} combination)? Even the old
mouseDown: method here was unreadable, but the patch realy is
incomprehensible for me in its current form.
Fred
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev