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 { NSTableColumn *tb; NSCell *cell; NSRect cellFrame; id originalValue; tb = [_tableColumns objectAtIndex: columnIndex]; cell = [tb dataCellForRow: rowIndex]; originalValue = RETAIN([self _objectValueForTableColumn: tb row: rowIndex]); [cell setObjectValue: originalValue]; cellFrame = [self frameOfCellAtColumn: columnIndex row: rowIndex]; [cell setHighlighted: YES]; [self setNeedsDisplayInRect: cellFrame]; /* give delegate a chance to i.e set target */ [self _willDisplayCell: cell forTableColumn: tb row: rowIndex]; if ([cell trackMouse: theEvent inRect: cellFrame ofView: self untilMouseUp: [[cell class] prefersTrackingUntilMouseUp]]) { id newValue = [cell objectValue]; if ([tb isEditable] && ![originalValue isEqual: newValue]) { [self _setObjectValue: newValue forTableColumn: tb row: rowIndex]; } } RELEASE(originalValue); [cell setHighlighted: NO]; [self setNeedsDisplayInRect: cellFrame]; } 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. 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. Fred Matt Rice wrote: > 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. > _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev