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

[Quentin Mathé]

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é
address@hidden