Linux: Dark window when dragging if compositing is disabled in window manager

[juangburgos]

Hi,

I am using the library in the QUaModbusClient open source project. I have tested on Windows ans CentOS and all fine. I have tried on Lubuntu and it seems there is some issue when dragging over a detached dock into a Layout.

Has something similar happened to anybody? Is it an OS issue or a library issue?

Thanks

[githubuser0xFFFF]

Could you please elaborate what the exact issue is? Is the problem reproducible with the demo application.

Which QT version do you use and what are your global dock manager configuration flags?

[juangburgos]

Hi,

Yes, the issue is reproducible with the latest binary available here (AppImage).

Qt version is 5.12.3. I do not use any specific global dock manager configuration flags, I just ise the library as shipped by the github repo (it is actually included in the project as a Git submodule).

Best,

[githubuser0xFFFF]

I mean, is the problem reproducible with thr ADS demo app.?

[juangburgos]

I would need to deploy it. Will come back to you on that.

[hhslepicka]

@githubuser0xFFFF I can reproduce this issue with the latest code and demo app.
With Linux when dragging the dock I get a black overlay over the whole application. When the dock is docked it goes away.

[githubuser0xFFFF]

It is not a generic Linux issue. I tested it on Ubuntu 19.10 an Kubuntu 18.04 and it works. According to another user this problem occurs, if compositing is deactivated in Linux.

@hhslepicka Which Linux distro do you use?

[githubuser0xFFFF]

@juangburgos Can you please tell me which Lubuntu version you use?

[hhslepicka]

I use RHEL 6 & 7

[iam-peter]

This issue is caused by disabled compositing via the window manager.
https://doc.qt.io/qt-5/qwidget.html#creating-translucent-windows

Creating Translucent Windows
Since Qt 4.5, it has been possible to create windows with translucent regions on window systems that support compositing.
To enable this feature in a top-level widget, set its Qt::WA_TranslucentBackground attribute with setAttribute() and ensure that its background is painted with non-opaque colors in the regions you want to be partially transparent.
Platform notes:
X11: This feature relies on the use of an X server that supports ARGB visuals and a compositing window manager.
Windows: The widget needs to have the Qt::FramelessWindowHint window flag set for the translucency to work.

My current setup is running Xfwm4 as a window manager, because it allows me to easily enable/disable compositing via the following command: xfconf-query -c xfwm4 -p /general/use_compositing -s false.
If compositing is disabled, I get the following result in the demo application when dragging around a DockWidget:

This behavior is caused by the QWidget background set to be translucent.

Qt allows for checking if compositing is running or not with bool QX11Info::isCompositingManagerRunning() documentation
A workaround could utilize the following statement:

#ifdef Q_WS_X11
    if(QX11Info::isCompositingManagerRunning())
        setAttribute(Qt::WA_TranslucentBackground);
#endif

For now I came up with two workarounds for the disabled compositing issue:

1. Use QRegion similar as in the Shaped Clock example to not rely on translucent QWidget. A drawback would be the missing transparency on the drop regions. Maybe it is possible to use a different pattern on the QBrush to achieve a sort of see through look.
2. Use a screenshot of the MainWindow as the background of the DockOverlay. The drawback is that the background would be static as long as the drag operation is ongoing.

[juangburgos]

Sorry, I was AFK on holidays. My experience looks the same as for @iam-peter on Lubuntu 19.10.

[githubuser0xFFFF]

@iam-peter Thank you for the detailed analysis and the two proposed solutions.

The second solution sounds good. Because docking is possible in all floating widgets, I think taking a sceenshot of the MainWindow is not enough. I could imagine the following flow:

1. Hide the current overlay to prevent its visibility on the screenshot in the next step
2. Take a screenshot of the whole screen and copy the part that will be covered by the overlay or create a screenshot of just the part the will be covered by the overlay.
3. Create a bitmap that is a merge of the captured screenshot and the colored overlay.
4. Set this bitmap as background for the DockOverlay
5. Show the DockOverlay

For the floating DropPreview I would simply deactivate transparency.

[githubuser0xFFFF]

I have thought about the topic again and I think the solution I suggested above does not work that way.

Because the overlay is in front of the dragged widget, the floating widget will be behind the overlay and because the overlay will display a screenshot of the DockContainer beneath it looks like the dragged widget will be behind the DockContainer. In the animated screenshot from above, the dragged widget is not visible and this will not change, if the overlay displays an image.

An option would be, to dynamically make the DockOverlay a child widget of the DockContainer / DockArea for which the overlay is provided. I just created a test. I added the following lines into the constructor of the Qt basiclayouts example:

QFrame* Overlay = new QFrame(this);
QColor color = this->palette().highlight().color();
color.setAlpha(64);
Overlay->setStyleSheet(QString("background: %1; border: 1px solid %2;").arg(color.name(QColor::HexArgb)).arg(color.name()));
Overlay->setGeometry(0, 0, this->width() / 2, this->height());
Overlay->show();

This is the result:

This works without Qt::WA_TranslucentBackground.

Here comes the problem of this solution: the DockOverlayCross and the drop icons will be behind the dragged FloatingWidget. That means, if you drag the widget, it will hide the DockOverlayCross. But because the mouse position is almost in the top left corner of teh FloatingWidget, it should be possible to hit the right position.

[hhslepicka]

@githubuser0xFFFF this seems like a good escape route in case composition is not available for the OS.
I would be more than happy to test a candidate fix for that.

[githubuser0xFFFF]

@hhslepicka @iam-peter I create a new branch linux_no_compositing to implement a proof of concept of the idea I described above. You can checkout this branch, compile it and test the demo application. The branch shows, that the docking is not working as intended. Here are the problems:

1. Because the dock overlay is now a child of the dock container / dock area, the dock overlay cross is limited by the geometry of the dock area. That means, for small dock areas, the dock area cross can not overlab the dock area:

2. If the target dock area is in a floating window, then the floating window will be stacked over the dragged window as soon as the dock overlay will be reparented to the floating dock area. That means the dragged window is behind the floating window - that looks really strange:

So to summarize the results: making the dock overlay a child of the target dock area works partly but has to many issues to be a good workaround for linux systems with compositing disabled.

[hhslepicka]

@githubuser0xFFFF thank you for pursuing the fix for this issue.
I just tested it in here and here are my findings:

Good Findings:

• The black screen is gone

Bad Findings:

• The main screen at the demo gets gray now instead of black and only sometimes I can see the docking areas but docking works.
• When the screen is floating I can dock successfully into it as long as it is not over the main screen of the demo.

Other than the two items above the fix seems to be moving in the right direction I would say.

[hhslepicka]

@githubuser0xFFFF did you have a chance to look at this issue some more?
Please let me know if you would like me to help with tests.

[githubuser0xFFFF]

This issue ist not easy fixable and requires a lot of work. At the moment I do not have the time to fix this and I'm also not really happy to spend that much time because somewhere in some Linux distribution is compositing disabled.

[juangburgos]

I find that understandable. Maybe just mention a caveat in the main README of the repo for Linux mentioning that compositing must be enabled with some links on where to find information about enabling?

Then leave the issue open for help if somebody steps up with a contribution.

[githubuser0xFFFF]

This is a good idea. But I cannot tell, how to enable compositing because I don'k know it and because I think it is different for different Linux distributions - or is there a generic way?

[hhslepicka]

@githubuser0xFFFF I completely understand your point. No problem at all. We will look at our side how to enable Compositing. Feel free to close the issue.

[vitcpp]

Hi

I have the same issue with black screen on CentOS 6. The problem is because the overlay window is created as a borderless top level system window. It is probably the reason you rely on composite extension. Actually, I think the better approach is to create the overlay window (and cross window) as a child of the parent window. In this case parent window contents will appear as the background of the overlay window like it seems to be transparent. I tried to do it in my project and it seems I suceeded to fix it.

[githubuser0xFFFF]

Hi,

great to hear that you suceeded fixing the issue. Would be great, if you could create a pull request for your changes so that I can test it. I already tested several solutions by myself like you can see in the messages above.

[vitcpp]

Hi,

Yes, but I have to fix a positional issue related to the change the parent of overlay widget. I briefly went through some comments. What you are proposed to use the screenshot of the background - it is a good way but you shouldn't do it yourself. Actually Qt already does it and there will be no issue with static background.

[juangburgos]

Hi,

Yes, but I have to fix a positional issue related to the change the parent of overlay widget. I briefly went through some comments. What you are proposed to use the screenshot of the background - it is a good way but you shouldn't do it yourself. Actually Qt already does it and there will be no issue with static background.

Merge request, merge request, merge request! 🙂

[githubuser0xFFFF]

@juangburgos Vitaly created pull request #217 to fix this issue. Could you please test his fix?

@vitcpp Thank you Vitaly for the pull request

[githubuser0xFFFF]

@juangburgos Have you tested the changes from Vitaly?

[githubuser0xFFFF]

@iam-peter Hi Henning. Vitaly created pull request #217 to fix this issue. Would be great, if you could test this and give me some feedback if his solution works.

[iam-peter]

@iam-peter Hi Henning. Vitaly created pull request #217 to fix this issue. Would be great, if you could test this and give me some feedback if his solution works.

@githubuser0xFFFF I pulled the fork from Vitaly, deactivated compositing and it works.

[juangburgos]

I compiled QUaModbusClient with the master branch, and it is still rather un-usable in most Linux virtual machines:

[githubuser0xFFFF]

Yes, I know. Vitaly promised to fix this, but obviously he didn't succeed.

[githubuser0xFFFF]

I close this issue because I'm not able to fix this and it does not seem important for other people to fix this.

[Tectu]

This is unfortunately still an issue plaguing many of us daily :(

[githubuser0xFFFF]

@Tectu Yes, it's a shame that not a single Linux user could fix this issue or even tried it.

[ssokolow]

@Tectu Yes, it's a shame that not a single Linux user could fix this issue or even tried it.

You're assuming we know how to write C++ and aren't just PyQt plebs.

[Tectu]

@Tectu Yes, it's a shame that not a single Linux user could fix this issue or even tried it.

@githubuser0xFFFF It's a bit disconcerting if the author / maintainer of the project is saying that it's a difficult problem to fix.
Other than me not being a Linux user (BSD here), I'm happy to help where I can. But I think we'd need you to lead the effort in one way or another. There is undoubtedly a lot of experience and intimate knowledge of how this library is designed and how it works on your end. Something that everybody else is severely lacking.

You wrote:

I close this issue because I'm not able to fix this and it does not seem important for other people to fix this.

What exactly is preventing you from fixing this? (I don't mean that in a bad/negative/offensive way !!!)
As I understand, the underlying "issue" is that Qt::WA_TranslucentBackground requires an X server with ARGB and compositing. But right now it's not clear to me whether everything works as intended if that requirement is met. Furthermore, it does seem like there are some potential solutions/workaround that could be employed but they require some design change.
If you could share what you'd need to proceed, I'm sure others can chime in to help.

In any case, as others have mentioned, it is 100% fine - without questions or judgement - if you don't feel like spending time on "supporting Linux" or tackling this problem in general. But don't mistake lack of contribution for lack of severity/interest :)

If this is a personal dislike against Linux, there are other operating systems / platforms out there that are affected by this issue. While Linux might be "a mess" (to quote you from #451), this does not seem to be a Linux specific problem from what I can tell but rather an X related issue.

[githubuser0xFFFF]

@Tectu This is an open source project and any user or developer can fix issues. There are a lot of issues that have been fixed by ADS users. Most ADS users work on Windows but most issues are on Linux. I'm neigther a Linux expert nor do I have the time to fiddle around with each Linux window manager.

Therefore I hoped, that a Linux user will fix this - but no one fixed this for some years.

Another option would be some kind of commercial support. How much money would you spend, to see this fixed?