Drag and Drop within a QWindow window container on Linux

NickJT

Hello,

I am in the process of porting an application from its originally developed OS, Windows 10, to RHEL 7.7.

This program is actually two Qt projects. The first project (outer) starts and will spawn N number of the second (inner) project/process. Those inner processes are then captured using the window ID and:

QWindow *window = QWindow::fromWinId(id);
QWidget *widget = QWidget::createWindowContainer(window, this);

and added to a QStackedWidget to give the appearance of multiple different 'workspaces'.
Ultimately this architecture exists because each workspace needs seperate process environments.

One of the widgets that lives in the inner 'workspaces' uses drag and drop to allow the user to drag entries from a QTableWidget to a QWidget with custom dragEnterEvent(QDragEnterEvent *event) and dropEvent(QDropEvent *event).

This works as expected on Windows 10.

However, when testing on RHEL7.7, I've discovered that when the workspace application/process is inside the window container (inside the outer application), drag and drop does not work.

Some observations:

The dragEnterEvent is never received/event handler never called.
The mouse cursor gives the appearance across the entire workspace/inner app that the drag is being accepted. (In a working instance, aka windows10, only the area with an implementation of dragEnterEvent which acceptProposedAction()s will show that type of cursor.)
When not within a window container, everything works fine. I can both run the inner application standalone and demonstrate dnd working on RHEL, and drag the problematic widget out of the workspace (because it is a qdockwidget) turning the widget into a toplevel window, where it will work fine.
DND within a window container has worked without a hitch on windows 10.

I made a minimum working example of my problem. It is two projects, the outer just being a QMainWindow and the inner a QMainWindow whose central widget contains a horizontal layout with two QTablewidgets. The left table has setDragEnabled(true) and the right setAcceptDrops(true). When the outer project starts, it starts one instance of the inner and captures it with a window container and the above code.
It can be compiled with mingw on windows and gcc on linux.

Here is the test app on linux, you can see how it is showing acceptance for the left table even though it should not accept drops.

Here it should be accepting the drop, as the cursor shows, but releasing the cursor will not place the item.

Here is the inner app running standalone. Everything works as expected here.

Here you can see windows running the test project. Ignore the graphical glitch on the cursor, thats SnagIts fault. You can see how the left table is rejecting the drop as it should.

Here is windows accepting the drop on the correct table, if i release the cursor it will add the item to that table as it should.

I found this code fix that was mention in a bugreport about drag and drop not working on Linux. However the bug report did not mention anything about window containers and seemed to imply it was not working at all with XCB. The fix seems to be for 5.4 anyways.

I am using 5.9.6 on Windows10 and 5.9.7 on RHEL7.7. I don't see anything mention in the release notes for 5.9.7 that would imply a difference in DND functionality between the two versions.
I also had to build 5.9.7 from source and everything is 32bit if that matters. Here are the options used in the configure script before building Qt:

-v -opensource -confirm-license -platform linux-g++-32 -no-opengl -qt-xcb -cups -prefix /opt/Qt5.9 -nomake examples -nomake tests -skip qt3d -skip qtandroidextras -skip qtcanvas3d -skip qtcharts -skip qtconnectivity -skip qtdatavis3d -skip qtdeclarative -skip qtdoc -skip qtgamepad -skip qtgraphicaleffects -skip qtimageformats -skip qtlocation -skip qtmacextras -skip qtmultimedia -skip qtpurchasing -skip qtquickcontrols -skip qtquickcontrols2 -skip qtscript -skip qtsensors -skip qtserialbus -skip qtserialport -skip qtspeech -skip qttools -skip qttranslations -skip qtvirtualkeyboard -skip qtwayland -skip qtwebchannel -skip qtwebengine -skip qtwebsockets -skip qtwebview -skip qtwinextras -skip qtx11extras

Any ideas would be much appreciated. I'm pretty much out of ideas.

The one guess I have is it might involve window 'focus' and the inner window going out of focus maybe when the drag event starts?

I have the test project zip'd and available, just not sure how to attach it here.

Thank you so much in advanced for any help,
Nick

SGaist

Hi and welcome to devnet,

Do you have the same issue if you use the Qt version provided by RedHat ?
A more recent version of Qt ?

As for sharing your project, either a file sharing site or something like GitLab is fine.

NickJT

Alrighty, a year and a half later, and we have finally gotten around to trying out a newer version of qt. I've compiled Qt 5.15.2 on RHEL 7.7 and still encounter the same problem detailed above. I've tried on both 64bit and 32bit architecture and haven't noticed a difference.

To briefly recap, the problem is Drag and Drop from within a QWindow window container does not work specifically on our linux build (RHEL 7.7, not sure about other distros). The same code works fine on Windows 10 (MINGW).

I am working now to get our minimal reproducible example outside the company network so I can post it here. Expect that within the next day or two.

At this point I guess I'm looking for potential work arounds or for someone to tell me this is a known bug with no solution.

Thanks in advanced!
Nick

NickJT

Here is the reproducible example which was pictured in the original post. Run TestInner to run the inner window normally, and observe how Drag and Drop works as expected. Then run TestOutter, which itself runs TestInner, to see how drag and drop no longer works once the TestInner window is contained inside TestOutter.

https://www.dropbox.com/s/5hw2y2ndkji8iix/TestProject.zip?dl=0

SGaist

RHEL is not the only one that is not working. KDE Neon is also concerned.

I do wonder if it's not related to the commented out code that you can see in the patch you linked.