How to preserve QLitView selection when context menu invoked

[ericwny]

I am using a QListView. I have implemented support for drag and drop by implementing a model for it derived from QStringListModel. I would like to invoke menu actions on an extended selection in the list view but, I don't want the selection to be changed by the right click. I don't want to have to override QListView if I do not have to.

Never mind. My problem was with breakpoints.

[ericwny]

I am not sure why but I seem to have this problem again. And it is not because focus is switched to the IDE for breakpoints. Is there a simple way to prevent right click from selecting an item in a QListView?

[jpn]

I just gave it a quick try and according to my test the selection doesn't change at all when the context menu is opened:


// main.cpp
#include <QtGui>

int main(int argc, char* argv[])
{
QApplication app(argc, argv);

QListWidget listWidget;
listWidget.setDragEnabled(true);
listWidget.setAcceptDrops(true);
listWidget.setDropIndicatorShown(true);

listWidget.setSelectionMode(QAbstractItemView::Ext endedSelection);
for (int i = 0; i < 10; ++i)
listWidget.addItem(QString::number(i));

listWidget.setContextMenuPolicy(Qt::ActionsContext Menu);
for (int i = 0; i < 5; ++i)
listWidget.addAction(new QAction(QString::number(i), &listWidget));

listWidget.show();
return app.exec();
}

Could you modify the above example to reproduce the problem?

[ericwny]

Sorry about the latest of this reply.

I am using QListView not QListWidget. But I'll try experimenting with the widget code.

[ericwny]

I just compiled and ran the code you posted and I see the same behavior basically. I figured why it could be missed. I select multiple items, then if I right-click and I happen to have the cursor over the item in the selection that has the dashed outline around (i.e. the last addition to the extended selection) then that becomes the selected item. (Just before the context menu is displayed). If I right-click anywhere else the selection is not changed. It seemed like it always happened to me because that is typical of my use - I will select multiple items and invoke the context menu immediately with the cursor over the last selected item.

Still, it seems like a bug.

[wysota]

Are you both using the same platform? The behaviour might be platform dependent.

[ericwny]

I am developing on windows. However I have never noticed this with any windows software and I don't think everyone had to code a workaround to deal with the default windows list control behavior.

[wysota]

I can confirm this behaviour on Linux with ExtendedSelection or SingleSelection mode. Other modes are unaffected. Therefore I assume this might be on purpose... especially that I personally find that behaviour logical.

[ericwny]

Therefore I assume this might be on purpose... especially that I personally find that behaviour logical.

:confused: :confused: :confused:

I am truly sorry. I do not want to appear churlish but I really could not disagree more. That is not logical or intuitive. It is just bad design. You have one user gesture overloaded with two behaviors. That alone is a classic design flaw. Either the right-click invokes the menu on what you have selected or it affects the selection. You can't have both. In a good design.

Does this sound like a likely user requirement?
"I need a control that invokes a menu of actions to be performed on a number of files I have selected in a list and oh, by the way, if I activate that control when I have the mouse cursor over the last file I added to the selection just forget what I said before and give me a menu of actions to perform on that file"

It's absolutely ludicrous to try and portray this behavior as good. What I suspect is most likely is that integrating Mac behavior with it's single button mouse has complicated the semantics of the selection models. That I can understand. I wouldn't be happy about it and I still think it's a bug to be addressed. But I could easily understand how it might have fallen out of a noble and heroic effort to balance the needs and paradigms of a variety of platforms. But please don't embarrass us both by trying to say there is nothing wrong. That it is entirely proper. Doing so insults either my intelligence or yours. Please believe me when I say I'd relish neither.

[wysota]

I am truly sorry. I do not want to appear churlish but I really could not disagree more. That is not logical or intuitive. It is just bad design. You have one user gesture overloaded with two behaviors. That alone is a classic design flaw. Either the right-click invokes the menu on what you have selected or it affects the selection. You can't have both. In a good design.
It is your right to disagree, but actually right click actions on my platform work this way and I find the behaviour logical.

When I access the context menu over any of the selected items, the selection is preserved. If I activate it on an item that is not selected, it becomes selected and the menu is invoked for it. I don't see why context menu should be invoked for some items when I'm pointing to some completely different item. But as I said - it is your right to find something else intuitive.

[ericwny]

OK. It sounds like you are not hearing/seeing what behavior I am complaining about..


When I access the context menu over any of the selected items, the selection is preserved.

That is not what is happening IF I ACCESS THE MENU WITH THE MOUSE CURSOR OVER THE LAST SELECTED ITEM
It is in the selection. I am not clicking outside the selection or over an unselected item. And if I access the menu with mouse over any other item in the selection the selection is preserved. It only happens when THE MOUSE IS OVER THE ITEM THAT I ADDED TO THE SELECTION LAST.
That item becomes the only selected item.

I apologize for shouting but I feel like I am not being listened to. Yes the behavior is largely consistent with the typical interfaces I have used and developed...except for this one annoying point. Which affects how I always use multiple selections and context menus. I would think it would be the normal scenario. You make an an extended selection and invoke the context menu over the last item selected. Not because you think that is right way to invoke a context menu or even because that is the way you have, through free will, chosen to do so but because that's where the cursor is when you finish selecting items and are ready to invoke the menu.


If I activate it on an item that is not selected, it becomes selected and the menu is invoked for it. I don't see why context menu should be invoked for some items when I'm pointing to some completely different item.

That I understand. We could disagree about it. My point of view is that the popup menu operates in the context of the list control. For me, when I right-click I am asking for a menu of things I can do with the currently selected items. It seems a bit anal for me to have to "color in lines", so to speak, and target my mouse pointer within the highlighted items. Why does the right mouse button have any say in the selection at all I say. The left button is for selecting period. But yes, we can disagree about these things. But that is not the issue here.

[wysota]

That is not what is happening IF I ACCESS THE MENU WITH THE MOUSE CURSOR OVER THE LAST SELECTED ITEM
It is in the selection. I am not clicking outside the selection or over an unselected item. And if I access the menu with mouse over any other item in the selection the selection is preserved. It only happens when THE MOUSE IS OVER THE ITEM THAT I ADDED TO THE SELECTION LAST.
That item becomes the only selected item.

That behaviour I cannot confirm. It doesn't work that way on my installation (Qt 4.4/Linux) - the selection is preserved if I right click on any of the selected items and is cleared when I right click on any other item


That I understand. We could disagree about it. My point of view is that the popup menu operates in the context of the list control.
I don't as the empty widget is subject to context menu itself, regardless of items it holds.


For me, when I right-click I am asking for a menu of things I can do with the currently selected items.
As far as I remember this is platform dependent.

If you want to change the behaviour you are getting, subclass the view and reimplement the mouseReleaseEvent or apply an event filter and modify the behaviour upon right-click, it should be 5-6 lines of code at most.