Re: recent change to NSTableView

[Matt Rice]

On Fri, Jan 1, 2010 at 4:11 AM, Wolfgang Lux <wolfgang.lux@gmail.com> wrote:
> Hi Matt!
>
> [I hope it is okay for you that I cc'ed this response to the GNUstep
> mailing list, since I think it could be of interest for other people.]
>
>> Hi Wolfgang, I had some questions about this change here, as I was
>> under the impression that this was already working except the
>> "unselected row" part worked differently
>> It would work for selected or unselected rows, e.g. so that clicking a
>> "check box" cell, in a table view which allowed dragging multiple
>> times would toggle the check box on and off,
>> it seems to me that this change would require you to unselect the row,
>> then select it again, to do things like toggle checkboxes? (i haven't
>> tried it)
>
> No. It is exactly the opposite. Without my change you had to click twice
> into a check box to toggle its setting when the table view allows dragging.
> The first time in order to select the respective row and then upon the
> second time the check box would really toggle. This behavior was really
> annoying and it is not necessary when dragging is disabled. With my change
> a click into a check box will have an immediate effect whether dragging is
> enabled or not. (I guess, it is needless to say that OS X behaves the same).
>
>> anyhow the way it was supposed to work was that if
>> (draggingOperationPossible == YES) by the time it got to NSLeftMouseUp
>> it meant the same as "dragging never occured",
>> I haven't looked at this code in a while so it could be that something
>> changed inbetween the last time i've looked at it and your change
>> which broke the original behaviour, or i could easily be missing
>> something subtle.
>
> I guess the point you are missing is that draggingOperationPossible is set
> to NO when you click into an unselected row.

Ahh, yeah I see that now, thanks for pointing it out, also in this line,

if (!didTrackCell && currentRow == _clickedRow)
it makes perfect sense to me now that 'currentRow == _clickedRow'
portion of the statement means, don't track the cell if the row is
different from the row which received the initial mouseDown, and has
nothing to do with the 'selectedness' of the row


> Now this may be different from
> when you looked at the code last and it is certainly different from OS X
> where you can drag an unselected row.

yeah I'm probably remembering wrong, it could be i had it working
locally but never got it in cvs
to let the mouse selection stuff stabilize before commiting further
changes which i never got back to

> However, I deliberately did not
> attempt to implement this on GNUstep -- at least for now -- since after
> code inspection I felt unsure that the current code is prepared to handle
> dragging an unselected row (plus it may break existing programs).

yeah, at least going to need to move some code around, so that the new
selection is computed before the dragging code happens, so that you
dragging an unselected row doesn't drag the pre-existing selection,
doesn't look entirely trivial, but the main reason it is the way it
is, was a limitation of the old-old mouseDown: event looping code
which computed the new selection at the end of the loop see
http://svn.gna.org/viewcvs/gnustep?rev=24468&view=rev

My guess would be you could just move the following code up above the
dragging code and then the checks would pass (or remove them as they
would be kinda superfluous)

mouseLocationView.x = _bounds.origin.x;
oldRow = currentRow;
currentRow = [self rowAtPoint: mouseLocationView];
if (oldRow != currentRow)
 {
   COMPUTE_NEW_SELECTION;
 }

(above the line)
if (eventType == NSLeftMouseDown)

> Furthermore,
> I had not enough time to test such change thoroughly. So feel free to
> consider
> my change a stop gap measure and improve it.

Understood, testing the myriad of configurations of NSTableViews can be painful,