In a QTreeWidget I want to be able to reorder items using InternalMove AND receive drops from another tree in my application.
If I set dragDropMode to InternalMove I cannot drop items inside it. However, if I set it to DragDrop it lets the user drag items out of the my QTreeWidget.
Is there a way of preventing this? Is there another way around the problem?
If you are not worried about drags outside of your application, maybe setting the DragDropMode of the other QTreeWidget in your application (or anything that derives from QAbstractItemView for that matter) to:
treeWidget->setDragDropMode(QAbstractItemView::DragOnly);
is enough to get the desired behavior. This does not prevent the items of the QTreeWidget in question from being dragged, but they cannot be dropped in the other tree, while you can still drop them (and the items from the DragOnly tree) into the tree that accepts drops. Does this help? (Admittedly not the most intricate way to attack the problem but performing some local tests it seemed to work)
Related
I have a set of QML items distributed all over my UI. They display data from a remote device and their content needs to be updated regularly. The Items are spread on several tabs and hidden in nested ListView instances, so most of them won't be visible to the user all the time.
In order to keep the bandwidth low I want to update only those items that are currently visible to the user.
I am looking for the right hook to get the information which of these Items is currently displayed from within the Item, without relying on information from the parents. If they were all placed in ListView delegates I could use the delegate's Components onCompleted and onDestroyed signals. Since this is not the case I am stuck at finding out how to get this information.
Am I missing something here? Is there an onPaintFinished signal or something similar? My workaround would be to add that logic to the parent containers, but that would be tedious, since there are several kinds of container that can contains these display Items.
Instances that are on delegates of a ListView will not exist until they would be in the visible range or the cache range around the visual area of the list view. If the delegate moves outside of that range, it is destroyed. So, no need to worry about instances hidden there.
Furthermore, items are currently not visible are also not drawn. They are not entered into the scene graph, and hence, not rendered. So, instances of your items appearing on tabs that are currently not current will also not be drawn. However, these items do still exist of course.
Figuring out if an item is effectively visible or not is quite a hard problem though. QML delegates part of that to OpenGL (clipping for instance). There is not feedback on the result of that. You could in theory lift that information out of the renderer, but that would require customizing that and that is very hard. You could take a look at the heuristics that GammaRay uses to warn about items not being visible. Perhaps you can take some inspiration from that.
I have created a widget which inherits QListWidget.
My goal is for it to accept files dropped into it from an external file manager, and for the user to be able to reorder the elements in the widget. I can achieve both, but not at the same time.
If I just set
myWidget->setDragDropMode(QListView::InternalMove);
myWidget->setDragEnabled(true);
I can reorder the items within the widget, but I can't drop external items into it.
If I reimplement the dragMoveEvent, dragEnterEvent and dropEvent events, all of them just having acceptProposedAction(); and some debug messages inside them, I can drop external files into my widget, but I can no longer rearrange the items.
Is there a way to have the above two at the same time, or do I have to manage the items myself in the reimplemented functions? If so, how can I know if a dropped item is internal or external, and how can I know from which position it was taken and into which position in the list it was dropped into?
If I parse the mimeData which I got from the event, I can see whether it as a file or a text, and I get "qabstractitemmodeldatalist" if it was an internal item, but it still doesn't give me its position.
I can check event->pos() to know in pixels where the drop has been made, and event->source() to learn about what was dropped there, but is this really best practice, to start calculating pixel values and adding objects "manually"?
The solution was very simple: I just had to call the functions of the parent class at the end of each function I've overridden.
void myWidget::dropEvent(QDropEvent *event)
{
do_stuff_with_received_data(event);
QListWidget::dropEvent(event);
}
Using Pyside, but a general Qt question:
I am building a Qt app with a controlling QMainWindow. From this window the user can open other QMainWindows (or QDialogs) and from some of those she can open more. The user is intended to think of the first QMainWindow as "the app" and the others as lots of different views on more or less the same data.
So I'd like all the windows to be independently stackable so the user can set up the screen to their own requirements. In particular I want the user to be able to bring the first QMainWindow on top if wanted. But I don't really want each window to have its own task bar entry (though I can live with that). Also I would like them to minimise and restore together, and I would like them all to close when the first main window closes.
If I parent them all on the first mainwindow it works nicely except they stay on top of it which is not what I want.
Instead I have it kind of working by making them all independent with parent = None. Then I register them all with the main window and close them all when it closes. But this makes them a bit too independent - they minimise separately and have their own task bar entry.
Am I missing some obvious fix to this? Is there any easy way (a flag?) to stop the children staying on top of the parent?
Or is there some UI guideline that I am breaking by desiring this?
Or is there a cleaner design somehow? I thought of adding a dummy parent that they could all descend from but maybe that's messy. Would that parent need a visual presence? I wouldn't want that.
Suggestions?
You can have as many QMainWindows as you want, or parentless QWidgets. I think the best way to handle your situation is to create your own pseudo parent-child relationship like this:
In your QMainWindow subclass, store a QList of all the QWidgets you want it to manage. Then, again in your QMainWindow subclass, reimplement methods such as QWidget::closeEvent(), QWidget::hideEvent() (for when the window is minimized), and QWidget::showEvent() (for when it is restored) so that it also closes, hides, or shows all of the widgets in its QList. Make sure to also delete them in the QMainWindow subclass's destructor. Now, whenever you create a sub-window, pass the main window a pointer to it not as a normal QWidget child, but just so that it can be added to the main window's QList of QWidgets to manage. E.g.:
MainWindowSubclass::addPseudoChild(QWidget *pseudoChild)
{
myListOfPseudoChildren.append(pseudoChild);
}
Another alternative that hasn't been mentioned yet is populating a QMdiArea with QMdiSubWindows. It doesn't do exactly what you asked for, but it's a pretty clean design nonetheless.
So I thought I would add what I eventually settled upon. This was particularly inspired by the comments of #leemes (Thanks - good stuff) and a little experimentation of my own.
I used the code attached here DetachTabExample
to develop a "Detachable Tab" widget and tab bar. This allows tabs to be dragged outside the main window when they become independent windows. Then if closed they return to the tab bar.
Then I placed all my content in the QMainWindow but in separate tabs. The users can drag the ones they want out on to the other monitor. Seems to be working fine. There are still some extra windows that I have floating but it has cut down the clutter and clarified the structure.
I have searched the web for possibilities to realize this but haven't found a solution. Is there a simple way of removing an item from the list that is dropped on a non-receiving area or even outside the application's window?
So far I accept the delete key for removing items by means of a shortcut:
QShortcut *shortcut = new QShortcut(QKeySequence(Qt::Key_Delete), myList);
shortcut->setContext(Qt::WidgetShortcut);
connect(shortcut, SIGNAL(activated()), this, SLOT(deleteSelection()));
But since I add items to the list via drag and drop, I would like to be able to remove them in the same way, too. The items in the list can also be ordered via drag and drop.
Any hints or links are appreciated.
This seems to work for me:
The drag-and-drop action should be Qt::MoveAction
Ensure the parent of the QListWidget (e.g., QDialog) has the following:
dragEnterEvent() implemented
dropEvent() implemented (ignore the mime data here)
setAcceptDrops(true);
Ignoring the mime data in dropEvent() in a Qt::MoveAction should be equivalent to a item remove operation.
Good luck!
I searched but couldn't find my answer, I'm sure it's easy for anyone with a little experience. I have multiple datagrids on a page, each one I want sortable with drag and drop, but I don't want items drug from one control to the other. How can I prevent a user from dragging an item out of a conrol. I would prefer to have it just stop moving with the mouse, but I am prepared to just completely cancel out of the dragging if need be.
I was trying to do something like this
dragExit="dragEvent.CANCEL"
This is obviously wrong, but I can't find the correct way to do it.
Thanks in advance.
~Mike
Ok, so you have an app with multiple drag/drop datagrids, and you only want items dragged within a datagrid, and not from 1 to the other, is how I understand this.
What you need to do is create a custom dragDrop event handler for each datagrid which has the following command: event.preventDefault(). This in effect will stop a datagrid from receiving items from another .
This does not prohibit the dragging an item outside its host's borders, but it will prohibit the item being dropped into a different datagrid.
HTH.