[Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSTableView.m [NibCompatibility]
CVSROOT:/sources/gnustep Module name:gnustep Branch: NibCompatibility Changes by: Gregory John Casamento [EMAIL PROTECTED] 06/01/14 14:30:01 Modified files: core/gui : ChangeLog core/gui/Source: NSTableView.m Log message: Corrected problem in initWithCoder and encodeWithCoder CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/core/gui/ChangeLog.diff?only_with_tag=NibCompatibilitytr1=1.2640.2.20tr2=1.2640.2.21r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/core/gui/Source/NSTableView.m.diff?only_with_tag=NibCompatibilitytr1=1.119.2.2tr2=1.119.2.3r1=textr2=text
[Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSTableView.m
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fred Kiefer [EMAIL PROTECTED] 06/01/08 17:48:34 Modified files: core/gui : ChangeLog core/gui/Source: NSTableView.m Log message: Intercell spacing change for NSTableView. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/core/gui/ChangeLog.diff?tr1=1.2642tr2=1.2643r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/core/gui/Source/NSTableView.m.diff?tr1=1.120tr2=1.121r1=textr2=text
[Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSTableView.m
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: matt rice [EMAIL PROTECTED] 05/12/31 13:50:30 Modified files: core/gui : ChangeLog core/gui/Source: NSTableView.m Log message: * Source/NSTableView.m (-mouseDown:): Copy the selected cell before tracking mouse, add comment. (patch previously reverted 2005-05-30) (-mouseDown:): Check for pointer equality in addition to isEqual: which doesn't work with nil. (fix for bug #15316) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/core/gui/ChangeLog.diff?tr1=1.2640tr2=1.2641r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/core/gui/Source/NSTableView.m.diff?tr1=1.119tr2=1.120r1=textr2=text
Re: [Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSTableView.m
--- Fred Kiefer [EMAIL PROTECTED] wrote: Enrico Sersale wrote: On 2005-05-28 06:34:22 +0300 Matt Rice [EMAIL PROTECTED] wrote: --- Enrico Sersale [EMAIL PROTECTED] wrote: On 2005-05-26 16:38:12 +0300 Fred Kiefer [EMAIL PROTECTED] wrote: CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by:Fred Kiefer [EMAIL PROTECTED]05/05/26 13:38:11 Modified files: core/gui : ChangeLog core/gui/Source: NSTableView.m Log message: Improved mouseDown call handling for table view. CVSWeb URLs: I think that it would be a good habit to try to run one or two of the (few) GNUstep applications before committing changes that can break things... just to elaborate.. this breaks (at least) gworkspace's view-list segfaults when selecting a row. 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. Enrico, It is not always bad to break things. If in this case my change showed some memory problem in GWorkspace and GNUMail this is a good thing. Provided we are able to fix it before the next offical release of course. So there was at least one benefit from applying the patch. :-) We should work together to track down the actual problems and fix them. GNUstep is stil full of hacks to get partial functionality working. We need to try to get it correct completely. anyhow the culprit being cell copy, which was added because NSComboBoxCell caches the cellFrame so it can pop up the window through a NSButtonCell's action... though it was causing multiple drawWithFrame: calls for the combobox cells with its setNeedsDisplay: then popping up in the wrong place... anyhow this seems to work in both cases.. Matt, You are surely correct about the fix for NSComboBoxCell, it should only mark its onl´e frame for a redraw. I am not totally convinced about the copy of the active cell in NSTableView. Copying the cell also gets done when editing is started for a cell. So cells that don't handle it correctly will also pose problems when edited. I will test this myself and propably apply it as well, to get GWorkspace and GNUMail working again. But my feeling is still that there is another problem hidden here, which we need to resolve. considering that GWorkspace was fixed wrt the cell copy, not copying the cell introduced a nasty bug, and GNUMail had a different issue altogether i recommited this cell copy, and cleared up the comment. to reproduce: edit a cell, select the same cell in a different row, selected cells object value becomes previously edited cells object value which has to do with selecting the new cell causing validation to occur on the edited cell. __ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSTableView.m
Hi Matt, matt rice wrote: Log message: * Source/NSTableView.m (-mouseDown:): Copy the selected cell before tracking mouse, add comment. (patch previously reverted 2005-05-30) (-mouseDown:): Check for pointer equality in addition to isEqual: which doesn't work with nil. (fix for bug #15316) did you test this new code with GNUmail and Gworkspace? I had to revert the copying the last time because of problems with these two applications. I agree fully on cell copying, but we need to asure that it has no negative effects on these widely used applications. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSTableView.m
On 2005-12-31 17:54:35 +0200 Fred Kiefer [EMAIL PROTECTED] wrote: Hi Matt, matt rice wrote: Log message: * Source/NSTableView.m (-mouseDown:): Copy the selected cell before tracking mouse, add comment. (patch previously reverted 2005-05-30) (-mouseDown:): Check for pointer equality in addition to isEqual: which doesn't work with nil. (fix for bug #15316) did you test this new code with GNUmail and Gworkspace? I had to revert the copying the last time because of problems with these two applications. I agree fully on cell copying, but we need to asure that it has no negative effects on these widely used applications. Fred It seems that both the apps have no problems. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSTableView.m
Enrico Sersale wrote: On 2005-12-31 17:54:35 +0200 Fred Kiefer [EMAIL PROTECTED] wrote: matt rice wrote: Log message: * Source/NSTableView.m (-mouseDown:): Copy the selected cell before tracking mouse, add comment. (patch previously reverted 2005-05-30) (-mouseDown:): Check for pointer equality in addition to isEqual: which doesn't work with nil. (fix for bug #15316) did you test this new code with GNUmail and Gworkspace? I had to revert the copying the last time because of problems with these two applications. I agree fully on cell copying, but we need to asure that it has no negative effects on these widely used applications. It seems that both the apps have no problems. Great to hear. Sorry for asking at all. I did only see your previous mail on the subject after sending mine :-( I had to catch up with a bigger backlog of mails and I tend to read the CVS changes first. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSTableView.m
--- Fred Kiefer [EMAIL PROTECTED] wrote:
Hi Matt,
matt rice wrote:
Log message:
* Source/NSTableView.m (-mouseDown:): Copy the
selected cell before
tracking mouse, add comment. (patch previously
reverted 2005-05-30)
(-mouseDown:): Check for pointer equality in
addition to isEqual:
which doesn't work with nil. (fix for bug #15316)
did you test this new code with GNUmail and
Gworkspace? I had to revert
the copying the last time because of problems with
these two
applications. I agree fully on cell copying, but we
need to asure that
it has no negative effects on these widely used
applications.
i did test GWorkspace, and lightly tested GNUmail,
but don't have an email server so couldn't really test
it well,
and tested my application which had previously had
problems with the cell copying, and didn't see any
issues,
i also felt that in this case isolated issues with a
few apps would be better than issue that effects all
editable table views.
so with GNUMail being another issue and GWorkspace
fixed, i'm hoping the previous sentance will be a
worst case scenerio (and cocoa seems to copy the cell
in this case with some light testing if that means
anything)..
i believe that the issue with GNUMail was...
if ([cell trackMouse:)
{
done = YES;
}
while (done != YES)
{
.. implement dragging source
}
which is backwards, cell tracking needs to happen
after initializing a dragging operation has been ruled
out.
__
Yahoo! DSL Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.com
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSTableView.m
Quentin Mathé wrote: Le 20 juin 05 à 00:05, Fred Kiefer a écrit : I did not see any further reply to this mail from Matt, apart from my own. Does this mean that the patch is generally accepted or is just nobody interested? As I uggested I would like to see the cell tracking code as a new method on NSTableView. Something like: - (void) trackColumn: (int) columnIndex row: (int) rowIndex withEvent: (NSEvent *) theEvent I fully agree because I must admit I'm unable to understand current code in this method (I'm not talking about Matt's patch). I have to admit that I still con't quite understand the event handling concept. Let me try to rephrase it in my words and you may correct me later on: When getting a mouseDown event in the NSTableView, we need to find out if this is starting a dragging. Only if not we send on the event to the cell to start tracking. My main concern is the fact currently table view handles selection and tracking on mouseUp for cells by default… but selection and tracking should be handled on mouseDown event with cells, except when dragging is turned on and the clicked cell returns NO for trackMouse:inRect:ofView:untilMouseUp: or startTrackingAt:inView: methods I think. That would match moreover current Cocoa behavior (except the minor difference decided by Matt for dragging, I think it is a better choice that Apple's one) To illustrate current issues with examples: - you have no selection change on mouseDown currently when you click on a table view with standard cells and dragging turned off (this feedback absence is really problematic for a combobox because its popup window is closed on mouseUp before the clicked row highlighting becomes visible in table view) - popup button cell doesn't show its menu on mouseDown (only on mouseUp) - combobox cell doesn't support editing with current delayed tracking model (but it could involve other issues too) As we may have missed a few events whlie determining if this is a drag operation, the cell and the table view needs to get one more event to process from the application directly. If I understand you correctly you say that this is the behavour on Cocoa. Still it looks rather strang to me. On the other hand we should try to get dragging from table views working again for the next release and your patch is currently the only one. If nobody disagrees, I would submit this patch, with the separate tracking method and a few comments added. My objection to the patch would be it is introducing duplicated code between NSLeftMouseDragged and NSLeftMouseUp handling with the new 'if (draggingPossible == YES)' statement, without implementing true custom cell support as a counterpart. Anyway I think we can apply the patch, it works well in my test (dragging seems to be fixed) even if it's probably a temporary solution in my opinion… May be when code will be reorganised, we may start to clean mouse events handling in a definitive way in order to support any kind of cells correctly. Just one still unclear idea: Dowe really have to dequeue the events we get in mouseDown:? If we would first get the event and see if there is a draggging event coming, we would let the cell do the dragging, if this is allowed, with the event still in the queue. And if there isn't an upcoming drag event we could dequeue the event and do normal processing in the table view. As I wrote, just an idea... Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSTableView.m
Le 20 juin 05 à 00:05, Fred Kiefer a écrit : I did not see any further reply to this mail from Matt, apart from my own. Does this mean that the patch is generally accepted or is just nobody interested? I'm interested by it, but I haven't found enough time before this week-end to really test it (with other recent table view changes). I will send my comments later today. Thanks, Quentin. -- Quentin Mathé [EMAIL PROTECTED] ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSTableView.m
Finally here are my comments… Le 20 juin 05 à 00:05, Fred Kiefer a écrit : I did not see any further reply to this mail from Matt, apart from my own. Does this mean that the patch is generally accepted or is just nobody interested? As I uggested I would like to see the cell tracking code as a new method on NSTableView. Something like: - (void) trackColumn: (int) columnIndex row: (int) rowIndex withEvent: (NSEvent *) theEvent I fully agree because I must admit I'm unable to understand current code in this method (I'm not talking about Matt's patch). I have to admit that I still con't quite understand the event handling concept. Let me try to rephrase it in my words and you may correct me later on: When getting a mouseDown event in the NSTableView, we need to find out if this is starting a dragging. Only if not we send on the event to the cell to start tracking. My main concern is the fact currently table view handles selection and tracking on mouseUp for cells by default… but selection and tracking should be handled on mouseDown event with cells, except when dragging is turned on and the clicked cell returns NO for trackMouse:inRect:ofView:untilMouseUp: or startTrackingAt:inView: methods I think. That would match moreover current Cocoa behavior (except the minor difference decided by Matt for dragging, I think it is a better choice that Apple's one) To illustrate current issues with examples: - you have no selection change on mouseDown currently when you click on a table view with standard cells and dragging turned off (this feedback absence is really problematic for a combobox because its popup window is closed on mouseUp before the clicked row highlighting becomes visible in table view) - popup button cell doesn't show its menu on mouseDown (only on mouseUp) - combobox cell doesn't support editing with current delayed tracking model (but it could involve other issues too) As we may have missed a few events whlie determining if this is a drag operation, the cell and the table view needs to get one more event to process from the application directly. If I understand you correctly you say that this is the behavour on Cocoa. Still it looks rather strang to me. On the other hand we should try to get dragging from table views working again for the next release and your patch is currently the only one. If nobody disagrees, I would submit this patch, with the separate tracking method and a few comments added. My objection to the patch would be it is introducing duplicated code between NSLeftMouseDragged and NSLeftMouseUp handling with the new 'if (draggingPossible == YES)' statement, without implementing true custom cell support as a counterpart. Anyway I think we can apply the patch, it works well in my test (dragging seems to be fixed) even if it's probably a temporary solution in my opinion… May be when code will be reorganised, we may start to clean mouse events handling in a definitive way in order to support any kind of cells correctly. Quentin. -- Quentin Mathé [EMAIL PROTECTED] ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSTableView.m
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
Re: [Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSTableView.m
--- Fred Kiefer [EMAIL PROTECTED] wrote:
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?
it differs quite a bit but I didn't test very much..
just what happens wrt dragging source table views wrt
trackMouse:...
(which i'll reiterate) they don't send the mouse down
until mouse up has been sent and it is determined that
a drag operation hasn't started.
also that starting dragging operation in no way
affects the selection, though (to state the obvious...
starting a dragging operation on a selection drags the
selection). I personally prefer the GNUstep behaviour
of starting a drag operation modifies the selection.
so the trackMouse: code has basically been moved into
3 places...
1) after it has been determined there is no dragging
operation in progress..
2) when the delegate returns no for
shouldEditTableColumn: in a double click event
and this was changed a bit to handle more than just
double click but 1 so that each successive click
for instance with a switch button changes the state.
3) if table view isn't a dragging source send
trackMouse:... immediately
and the double click code brought into the loop (since
its looping over the events -mouseDown: was not
getting called with a clickCount over 1...)
and after the trackMouse:... code set the
getNextEvent: flag if the current event isn't the
lastEvent so that it'll loop again and handle any
mouse down event so next time mouseDown: is called it
doesn't think we're extending the selection or
something... this happens for all but the first case,
where it doesn't matter since we're at a mouse up
event and it'll never get to the point of looking at
the getNextEvent flag.
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.
yes sorry about that, I accidentally overwrote my code
i had before the formatting changes, and wasn't
exactly ecstatic about that...
__
Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html
Index: NSTableView.m
===
RCS file: /cvsroot/gnustep/gnustep/core/gui/Source/NSTableView.m,v
retrieving revision 1.118
diff -u -r1.118 NSTableView.m
--- NSTableView.m 30 May 2005 17:01:21 - 1.118
+++ NSTableView.m 6 Jun 2005 00:12:24 -
@@ -3332,7 +3332,32 @@
{
NSPoint initialLocation = [theEvent locationInWindow];
NSPoint location;
- int clickCount;
+ // Selection
+ unsigned int modifiers = [theEvent modifierFlags];
+ unsigned int eventMask = (NSLeftMouseUpMask
+ | NSLeftMouseDownMask
+ | NSLeftMouseDraggedMask
+ | NSPeriodicMask);
+ unsigned selectionMode;
+ NSPoint mouseLocationWin;
+ NSPoint mouseLocationView;
+ NSDate *distantFuture = [NSDate distantFuture];
+ NSEvent *lastEvent;
+ NSIndexSet *oldSelectedRows;
+ BOOL startedPeriodicEvents = NO;
+ BOOL mouseUp = NO;
+ BOOL done = NO;
+ BOOL mouseMoved = NO;
+ BOOL draggingPossible = [self _isDraggingSource];
+ BOOL getNextEvent = YES;
+ NSRect visibleRect = [self
[Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSTableView.m
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fred Kiefer [EMAIL PROTECTED] 05/05/26 13:38:11 Modified files: core/gui : ChangeLog core/gui/Source: NSTableView.m Log message: Improved mouseDown call handling for table view. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/ChangeLog.diff?tr1=1.2528tr2=1.2529r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSTableView.m.diff?tr1=1.116tr2=1.117r1=textr2=text
