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

[Fred Kiefer]

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