Signals and Slots for drag and drop behavior
-
I've been using some interactive QListWidget items recently, and one of the use-cases calls for items to be drag-able between the boxes. Basically, there are three QListWidget items, and any 1 item can only exist in one of the widgets at a single time. Of course, there are buttons and keyboard short-cuts for moving the items. These are easily handled using the signal/slot paradigm. However, I was alarmed to find that there is no Signal associated with a Widget receiving a dropped Item.
I really didn't want to have to design a new Model/View framework ( by derived classes, of course ) that implements the dropEvent method. Why isn't there any signal in Widget for itemDropped or something. It seems like one shouldn't have to create a whole new derived class just to handle drag and drop events in standard widgets.
Perhaps I am missing something. How would one best go about handling drag and drop behaviors using standard widgets and NOT deriving special classes?
-
You can use event filters to catch needed events.
-
I know that event filters are an option. However, this seems like using a sledge-hammer to swat a fly. Furthermore, it requires addition of another class to my project, and that seems like a lot of overhead to respond to such a simple event.
Do you know if there is a specific reason why there is no "itemDropped" signal in QWidget? It seems like it would be very useful for many different types of widgets.
-
I'm not developer of Qt, but I think reasons are huge size of data that can be passed to dropEvent.
-
[quote author="dusktreader" date="1282082833"]I really didn't want to have to design a new Model/View framework ( by derived classes, of course ) that implements the dropEvent method. Why isn't there any signal in Widget for itemDropped or something. It seems like one shouldn't have to create a whole new derived class just to handle drag and drop events in standard widgets.[/quote]
I really don't understand why you wouldn't do that. Working with a list widget is quite dodgy at the best of times. Aside from that, the 'standard' class is the QListView, not the QListWidget. QListWidget is a 'convenience' class. Here's a few reasons why you should start writing your own derivative of QAbstractItemModel:
QAbstractItemModels allow you to work with your data in a much more straight forward manner (itemviews-ng is even better for what I've seen)
Increased flexibility (see also next item) -- You have way more and more convenient control over what your models will and won't do.
Decreased coupling -- You're separating data from it's representation, which is good. As an added bonus, you can hang your model in several other items (QComboBox, QTableView, QListView) without having to modify your data logic.
So heed this advice and stop working around a widget and start working in a QAbstractItemModel.
It took me a few days to get fully comfortable with the system in the beginning, but after doing one or two more complex models you really, yes really see the benefits of taking the step of writing a class that manages your data.
-
[quote author="Franzk" date="1282195626"]
I really don't understand why you wouldn't do that. Working with a list widget is quite dodgy at the best of times. Aside from that, the 'standard' class is the QListView, not the QListWidget. QListWidget is a 'convenience' class.
[/quote]I'm fully aware that the ListWidget is a convenience class. I'm also fully aware of the benefits of using a Model / View framework. However, in this case, there just isn't ample justification for suffering the overhead. I have 3 QListWidgets. One is initially populated with QText items which may be interchangably dragged and dropped between the three lists. This is all the functionality I need from these widgets aside from notifying the main window that an item has been moved.
Before you start lecturing me about coupling you should take a moment to recognize that you aren't an expert on my system, and you should ask a few questions about the data flow model before you start pontificating.
-
If you have such similar behavior for all three lists why not just use one event filter for them? It will not make a lot of additional code, but will help you fully. Maybe mvc is too overheading for your situation, but one event handler will be not too big.
As for me I'm agreed with previous speaker that QListWidget is something that can help in really simple cases and will cause some problems for more complex situations.
-
[quote author="dusktreader" date="1282239004"]
I'm fully aware that the ListWidget is a convenience class. I'm also fully aware of the benefits of using a Model / View framework. However, in this case, there just isn't ample justification for suffering the overhead.[...]
his is all the functionality I need from these widgets aside from notifying the main window that an item has been moved.[/quote]
What overhead exactly? The Model/View framework is used whether you are directly working with it or not. This means that from a code perspective you are introducing more overhead right now than you would have when you wrote your own model. You could have written one model (three models that have the same behavior? Derived from QAbstractListModel) that does exactly what you want in very nearly half a day, while you've been going at this through this forum for about two days now without any results so far.
I may not be an expert on your system, but I have done a great lot of 'simple' things with model/view over the last year and everything turned out to be simpler and easier writing a model than when using the widget equivalent.
-
[quote author="Franzk" date="1282280552"]
What overhead exactly?
[/quote]Code development overhead, maintainability, etc.
[quote]
The Model/View framework is used whether you are directly working with it or not.
[/quote]
I'm aware that the QListWidget utilizes the QListView framework.[quote]This means that from a code perspective you are introducing more overhead right now than you would have when you wrote your own model.
[/quote]
If you are accounting for code overhead from generated code, yes. However, I'm handing off the code to a customer, and I would like to keep it simple[quote]
You could have written one model (three models that have the same behavior? Derived from QAbstractListModel) that does exactly what you want in very nearly half a day, while you've been going at this through this forum for about two days now without any results so far.
[/quote]
I haven't been sitting on my thumb waiting for the fairy-code-mother to answer my question. I found a work around. This thread is more about wishful thinking. In retrospect, I probably should have put it under a bug report wishlist.[quote]
I may not be an expert on your system, but I have done a great lot of 'simple' things with model/view over the last year and everything turned out to be simpler and easier writing a model than when using the widget equivalent.[/quote]
I really don't mean any disrespect. I know the model/view framework is powerful and not that difficult. I've used it myself before. Granted, I need more practice, but it seemed like there should have been a simpler solution for the functionality I was seeking.