[Qt-interest] General problem with selection in QAbstractItemViewclasses (QListXXX QTreeXXX etc)

[Tony Rietwyk]

> Sent: Wednesday, 29 June 2011 21:55 PM
> 
> Hi,
> Just found an interesting problem with selection behaviour inside 
> QAbstractItemView classes (no matter which class it is 
> QListView, QListWidget, 
> QTreeView, QTreeWidget ... even created my own QTreeView with 
> QStandardItemModel 
> and my QItemSelectionModel etc etc). I've used selection 
> signals for such 
> purpose but now I need accurate information (need it for my 
> QTreView + 
> QStandardItemModel) when mouse is pressed so:
> 
> 1.MousePress event in itemView viewport
> 2.You can clearly see that item is selected (colored blue, 
> focus rect around it 
> ...)
> 3.Ask that item is it selected ... NO ?!?
> 4.Ok ask Selection model about that selection ? NO ?!?
> 
> 5.MouseRelease .... ahh item says that's selected :( ...it's too late.
> 
> That's pretty nasty. You can see selected item but code says 
> that item isn't 
> selected :(
> I can understand such behaviour in case when item is 
> checkable and mouse is 
> inside checkbox (so we cannot trigger such change because 
> user can move mouse 
> and release it ... checkbox shouldn't be updated...that works 
> correct), but 
> simple selection is wrong, because selection is updated when 
> mouse is released 
> and that's too late (it's already selected *visually* by mousepress).
> 
> IMO, if user see selected item on the screen , our item data 
> should be already 
> updated.
> 
> Maybe I should use QTreeView event filter not viewport ? 
> 
> Any clues / comments ? Should I open an issue about this ?
> 
> zeljko


Hi zeljko, 

A similar type of problem occurs elsewhere in Qt.  A double-click generates
Press, Release, DoubleClick, Release.  I have found that if the DoubleClick
triggers the dialog to close, then the following Release causes a Clicked to
occur on whatever widget is now underneath the mouse.  This problem never
occured in Delphi - I assume because it ignores the Release, if it is not
the same widget as the corresponding Press / DoubleClick (and there's been
no drag).  I worked around the problem by deferring the DoubleClick action
until the Release.  But it feels clunky.  

Unfortunately, design decisions such as this rarely get fixed - there is
simply too much code that has already been written based on it.  

Regards, 

Tony.