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

[Quentin Mathé]

Le 22 juin 05 à 00:17, Fred Kiefer a écrit :

Just one still unclear idea: Dowe really have to dequeue the events we

get in mouseDown:?

It depends.

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.

hmm yes somewhat, but that means we have to check clicked cell in order to know if it is a custom cell or not. 

More precisely, if it is a custom cell with single-click interaction like slider, popup etc., we let it manage mouseDown and the dragging, otherwise table view has to process mouseDown, to set up the drag, by the way we should have discarded any events between mouseDown and mouseMoved (for this dequeue part, that's what I'm observing with Cocoa). 

MouseDown processing when handled by table view would be the following:

- ignore it if the clicked cell is already selected --> dragging possible now

- update the selection if the clicked cell isn't selected --> selection change by "dragging" possible now

Well, I'm may be misunderstanding something…

And if there isn't an

upcoming drag event we could dequeue the event and do normal processing

in the table view.

Yes, but I'm unable to understand why we would have to dequeue the event (you mean mouseDown event, right ?).

I would say we have nothing special to do unless we have ignored mouseDown when waiting for mouseMoved and we need to process it with following events received until mouseMoved happens (that's what I'm observing with Cocoa). That means we have to store in an array such dequeued events in order to process them later.

As I wrote, just an idea...

It should work perhaps not exactly in the way you are describing, but I could be missing a detail.

Quentin.

--

Quentin Mathé

address@hidden