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

[Fred Kiefer]

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.
>