mouseBeginDrag and mouseEndDrag don't work in some cases

[ghost]

Hello,

I'm trying to integrate spix into my tests, but for some reason neither mouseBeginDrag nor mouseEndDrag move my mouse. Both functions activate drag mode, but if the mouse doesn't move on its own, it won't reach the target and therefore it doesn't actually accomplish anything.

It's weird because lib/src/Commands/DragBegin.cpp and lib/src/Commands/DragEnd.cpp already contain the following line:

env.scene().events().mouseMove(item.get(), midPoint);

OS: Arch Linux
Confirmed on X11 and Wayland
(QCursor::setPos doesn't work on Wayland anyway, therefore it can probably be ignored)

Edit: Maybe it's relevant that the objectNames I'm targetting are inside delegates. For the application, I'm using QGuiApplication and QQmlApplicationEngine, too. Simple clicking seems to work just fine (double click doesn't though, but I suspect that this would have to be implemented separately).

[faaxm]

The system-level mouse on the screen will never be moved by Spix (though I am working on something in that area ;) ), as Spix only pushes fake-events into the event queue of Qt. As a result, the Qt app will think that the mouse is in a different position than the actual mouse is.

Do the examples work on your system? If they do, the issue might really be due to the delegate. In that case, calling the getErrors() method of the TestServer (or its respective RPC counter part from a python script) will return a string that reports which objects have not been found.

[ghost]

Thanks for the answer.

Spix only pushes fake-events into the event queue of Qt

Then some of the fake signals are not working for me apparently. I agree, it's probably better to use that instead of setting up a virtual machine and everything.

Do the examples work on your system?

Yes, all the examples except RemoteCtrl worked perfectly for me. I only had to add pthread to target_link_libraries for their CMakeLists, otherwise compilation would fail. None of the examples make use of dragging though.

I'm using C++ instead of Python, but I've tried Python as well. spix::TestServer::getErrors was empty when called at the end of the executeTest function inside Tests (like in the Basic example). Calling existsAndVisible(path) with the path arguments put into DragBegin and DragEnd returned true. The only way it would work is if I manually move my mouse from the DragBegin location to the DragEnd location (of course with sleep functions inbetween to help my slow mouse get into position).

This is how the QML structure looks like:

There's a SplitView divided into three parts, each containing one ListView. The ListViews get their data/model from QML/C++ bindings. The left and right part are of type QList<QObject*> and the middle one is QAbstractListModel, if that is anyhow relevant.

[ghost]

Okay, completely disregard all the stuff that I've written above. ;)

I integrated Spix into one of the official Qt examples. The same bug happens there.

cmake . && cmake --build . && ./DragAndDrop to compile and run.

draganddrop.tar.gz

[faaxm]

Thank you for the example! Indeed this doesn't look good, and I'm not sure why this is not working as expected.
I used the drag/drop functionality of Spix only once for a proprietary application (not mine), but it implemented part of its drag'n drop handling using custom code. It did work in that case, but it was still a bit of a hassle to get to work and required the "cursor wiggling" I mention in #18. I am not sure if it would help to move the mouse more slowly onto the target location and move it around a bit more inside the target, before the button is released.

Another thing worth investigating would be if qt requires the mouse drag/drop events to be sent, as is done to simulate drops from the system onto a qtquick window (See QtEvents::extMouseDrop). However, these are usually associated with mime data and not qtquick objects.

Probably the best way forward would be to have a look in the qt source code and see how drag&drop is actually handled there.

[ghost]

@faaxm I don't really understand why you mislabeled my issue as a "question" and closed it. Didn't you confirm that this "doesn't look good" and that you're not sure "why this is not working as expected" in reponse to the official QML example that had the same problem?

[faaxm]

@jdu9 reopened issue to track potential progress

[faaxm]

When using python together with pyAutoGUI to control the mouse, this issue should be fixed. See the updated RemoteCtrl example in v0.2

[faaxm]

Will close this issue, since this can be done with PyAutoGUI and system events now and I don't see a way to simulate a double-click purely by posting the right QEvent, which is how the non-PyAutoGUI part of Spix works.