Wt

Hey Koen,

Thanks for following-up on this issue. I agree with you that the recent change to selection behavior is acceptable for many use cases, and possibly preferable for some, where it could reduce the likelihood of accidentally losing a selection built-up with ctrl-click. "Clear" functionality can easily be provided in an alternative way. For instance, in the case that prompted the issue report, a user has additional "clear all" and "select all" options.

That said, I think the previous select/clear behavior is probably closer to what most users are familiar with outside of Wt. Your comments about OS X prompted me to spend some time looking at the rebranded Thunderbird on Debian Linux (Icedove), as it provides the drag/drop interface that I use the most. From observation, it appears that Thunderbird assumes that a mousedown is starting a click until there is some mouse movement - at which point it provides a drag cursor. Timing does not seem to be a factor in making the determination.

I also found a discussion on stackoverflow that discusses implementing behavior similar to that observed in Thunderbird: http://stackoverflow.com/questions/6042202/how-to-distinguish-mouse-click-and-drag. I'm not sure how practical/desirable this approach would be in the Wt environment, but if you end up making any changes, I'd be happy to assist with testing.

Regards,

Bruce

I believe that the previous patch is potentially unsafe if a post() or other update affecting the model/view occurs while the mouse button is down. I'll submit an updated patch that invalidates the stored delayedClearAndSelectIndex_ in WAbstractItemView::setModel.

That still leaves the possibility that the row/column stored at mousedown may reference another element, or point outside the model, when the click is handled. However, it seems that the selection code is designed to handle this situation without error?