Linux: Layout system stuck

[delins]

I compiled the CentralWidgetExample, ran it and played around with the docking system. It often gets stuck as shown in this gif:

1. I undock a widget and drop it above the central widget, making it float.
2. I then repeatedly move it, keeping it floating.
3. At some point the layout system gets stuck. This seems to happen randomly, I haven't been able to see a pattern here. Usually it takes longer than this, but I kept this recording to keep the gif short.
4. The layout system is then stuck on top. I can't click anything below it. It captures all clicks on top of its bounding box, but ignores them.
5. I am able to move the parent window, but only by clicking its titlebar outside of the layout system's bounding box, as can be seen in the gif.
6. Closing the main window also deletes the layout system, so that's ok.

I see the following warning on stdout when compiled with Qt 6.1.3: qt.core.qobject.connect: QObject::connect: No such signal QComboBox::activated(const QString&) (line is Qt-Advanced-Docking-System/examples/centralwidget/mainwindow.cpp:99), but I don't know if that has anything to do with this problem.

It doesn't only happen with CentralWidgetExample: before I tried that one I had the exact same problem with a simple program I built that is similar to the Getting started example

I tried this on Qt 5.12.5 and Qt 6.1.3, and built ads both in debug and release. I'm using the latest commit for ads, b5b251d.
My system is Kubuntu 20.04.2 with kernel 5.4.0-80. My display manager is sddm. If it helps: I'm on dual 1440p screens and it happens with the application both on my left and right screen. I've got a good mouse so I don't think it's a button bouncing issue.

[delins]

I have the same issue with 3.7.0 and 3.6.3 (Qt5, ads in debug)

[githubuser0xFFFF]

Hi, I just tested the CentralWidgetExample (master branch) on a vanilla Ubuntu 20.04 and could not reproduce the problem. This is my configuration:

• Ubuntu 20.04
• Qt5.12.9
• gdm3 display manager
• single monitor
• ADS master branch

So I think the problem is somehow related to your configuration. You need to narrow down the problem. You need to find out, if the problem is related to your multi monitor setup or to your display manager. Here it works properly in Ubuntu 20.04, Ubuntu 18.04 and Kubuntu 19.04.

[delins]

Thanks for testing. My guess was that it was somewhat specific to my system as well (otherwise it would have been reported on already), but I haven't got any problems with other Qt based applications, or any other GUI stuff for that matter.

I don't currently have time to dive much deeper into this, but when I do I'll update this issue. Feel free to close it in the meantime if the open ticket starts to annoy you :)

[githubuser0xFFFF]

Ok, I will close it for now - feel free to reopen the issue if you have further information.

[delins]

I created and tested fresh vms of:

• Kubuntu 21.04 + Qt 6.1.3
• Ubuntu 20.04.3 + Qt 6.1.3 & Qt 5.12.11

I installed opengl with the packages libglu1-mesa-dev freeglut3-dev mesa-common-dev. I used the latest version of ads and tried both debug and release builds. I get the exact same behaviour as I got before with Kubuntu 20.04.2

[githubuser0xFFFF]

Ok, thank you for testing. Because I cannot reproduce the problem here, I cannot fix it. So feel free to create a pull request if you have a solution.

[OpenJeDi]

I have the exact same issue on MacOS, for as long as I am using the docking system (1,5 years).
I was just going to report the issue, but I guess adding to this one is better.

It seems to be performance-based: it looks like it misses mouse events or something.

[CS-Labs]

I'm also running into this issue as well consistently on RHEL7 when running the AdvancedDockingSystemDemo. So far this has been reproducible if I move a window around enough in an area that it can potentially be docked without actually docking it.

For example:

2022-02-28-17-51-04.mp4

EDIT: Forgot to add the qt version, this was occurring under 5.9.7 (only version tested).

[githubuser0xFFFF]

RHEL7 is not supported by ADS. Only Ubuntu Linux is supported at the moment. Sorry, I do not have RHEL7 and so I'm not able to fix this. I hope a Linux expert will take over this task / issue.

To help other people, you should post your system configuration:

Linux:
Qt:
Display Manager:
ADS Version:
ADS Configuration Flags:

[OpenJeDi]

I am having this issue on MacOS since the day I started using Advanced Docking System. So it is not contained to just linux.

I am using the master branch of Qt Advanced Docking System (that is built in my cmake build system), and always the latest release of Qt.

The issue occurs more in Debug, and more when using compute-heavy windows. It seems to be related to missing mouse events or something.

[githubuser0xFFFF]

Ah ok, I understand. My problem is, that I cannot reproduce the problem on Windows and Linux and this makes it impossible for me to fix it. Any ideas are welcome.

[OpenJeDi]

I will see if I can isolate a simple test case when I find the time.

For me personally, this issue is not that important as we only use Windows computers in production. Just my development laptop is macOS.

The issue could be larger than just Qt Advanced Docking System. I remember dragging of a normal Qt window getting stuck in "dragging mode" after releasing the mouse button in a window that was too intensive on the GUI thread.

[ruffianhy]

Have the same issue on CentOS, the floating overlay will show after release the mouse, it is triggered by a superfluous move event 'void CFloatingDockContainer::moveEvent(QMoveEvent *event)', I m curious why we don't monitor the mousePressedEvent or mouseReleasedEvent to control show or hide the floating overlay.
I have an idea to workaround this issue : keep a flag for mouse press status, if mouse status is released. we don' call updateDropOverlays

[githubuser0xFFFF]

@ruffianhy Thank you for this tip - that is the first valuable information that provides an information about the possible cause of this bug.

Could you please try to implement your suggestion to keep track of the mouse button state to see if it fixes the issue?

[ruffianhy]

@ruffianhy Thank you for this tip - that is the first valuable information that provides an information about the possible cause of this bug.

Could you please try to implement your suggestion to keep track of the mouse button state to see if it fixes the issue?

I m fresh for QT, after learning, I found the system titlebar's mouse event can not be captured by mousePressedEvent and mouseReleasedEvent. It looks like there are only two options left:

1. Customize the title bar. The ADS already implement a floating titlebar in the project which can catch up the event. Just set the env "ADS_UseNativeTile=0", it will work. I just wonder, for this, is there any easy way to use the same style as the system title bar?
2. Capture the XCB nativeEvent. For this way, I cannot find the mouse press event and mouse release event, but it seems we can use the XCB_FOCUS_IN and XCB_FOCUS_OUT to replace, the code will be:
   
   QEvent::WindowActive and QEvent::WindDeactive is also work here.
   BTW: For this 2 options, we still need to store a global mouse flag, and check it in moveEvent function.

[ruffianhy]

@ruffianhy Thank you for this tip - that is the first valuable information that provides an information about the possible cause of this bug.

Could you please try to implement your suggestion to keep track of the mouse button state to see if it fixes the issue?

need your suggestion for the ideas above.

[githubuser0xFFFF]

This issue has been fixed for Linux by @ruffianhy with pull request #401

[OpenJeDi]

Just FYI: the issue still persists on MacOS. The fix was linux-only, but I have the feeling it has the same cause: mouse events that are triggered/handled incorrectly somewhere.

The fix for linux does not seem to be applicable for MacOS and I am not familiar with the ADS code.

As I said: the issue is not critical for us as we only use windows and linux machines for production, but it is annoying for me because I often use a MacBook for development.

If I find the time, I will try and fix this issue but as I said I am not familiar with the ADS internal code at all.

[githubuser0xFFFF]

Sorry, but I do not have a Mac and I'm not familiar with MacOS so I'm unable to fix this and hope for a contribution from an experienced Mac user.

[OpenJeDi]

OK, I will be waiting with you :)

I will have a shot at it myself soon. I will try to follow the rest of the code in terms of structure and syntax and whatnot.