[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSTableView.m

From: Fred Kiefer
Subject: Re: [Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSTableView.m
Date: Sun, 05 Jun 2005 23:58:25 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050414

Matt Rice wrote:
--- Enrico Sersale <address@hidden> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]