Support floating docks on Wayland

[asemke]

When trying to undock a dock widget, the UI gets broken as shown in https://invent.kde.org/education/labplot/-/issues/1067. A similar discussion has happened here already in #288.

The comment in https://invent.kde.org/education/labplot/-/issues/1067#note_1128693 summarizes the problem and also points to how this problem was addressed for toolbars and dock widgets in Qt.

[githubuser0xFFFF]

Thank you for reporting this issue. I will not fix this but you can provide a pull request

[asemke]

remarkable quality assurance and project maintenance attitude.

[githubuser0xFFFF]

Remarkable understanding of open source philosophy.

I'm a single person and I do not have fun and time to fix each stupid problem of each esotheric linux distribution, linux compositor or linux window manager. 90% of ADS users are on Windows - 90% of ADS issues reported are on Linux - so Linux really sucks in this case . So if you need this urgently, you need to implement this by yourself.

[asemke]

Deletion of comments - is this your understanding of the open-source philosophy?

[githubuser0xFFFF]

I understand your frustration, that I do not fix the bug. But I'm not a Linux expert and I mainly work on Windows, so I always hope, that people working on Linux are able to help out fix such bugs. But the strange thing is, that almost no reported Linux issue of this kind is fixed by a contribution and I wonder why.

One thing I do also not understand is, that you say that you also contribute to Open Source projects. If you do this, then I would expect that you know how much time people spend in their spare time to maintain Open Source projects. So I do not understand, how you can write a sentence like "remarkable quality assurance and project maintenance attitude" in the issue section. How can you do this, if you know how Open Source works. Do you think this is the right way to communicate your wishes? I do not earn money with this project and spent a lot of time maintaining the library. But like I said before, most of the users of this Library are Windos but most of the problems reported are on Linux - this really frustrates me. What kind of attitude is this, to expect from me to fix your issues as quickly as possible and posting such sentence here?

[asemke]

There is no frustration on my side, just a different understanding and expectation as to how to handle such bug reports and as to how to improve the quality of the project that I'm the author of for all supported platforms. I didn't communicate any "wishes" here, I reported a bug. My comment was sarcastic since your reply didn't met these expectations and is not the usual way to handle such bug reports, at least not in the community that I'm a member of. I apologize for the sarcasm.

As I mentioned in the comment that you deleted, I do understand the challenges on your side - I know and feel them almost every day on my side, too, and I even gave a talk at the Linux App Summit a couple of years ago talking about challenges to maintain such open-source projects long-term. I also appreciate the effort you're putting into this library, I really do.

I don't expect you to fix this issue, but maybe somebody else who wants to contribute will pick up this work. Given the scope of the bug fix that is required for this problem, I don't expect to fix this issue "as quickly as possible", I nowhere mentioned this. Usually such bug reports are not closed so other people facing such problems are aware of the fact that it's already known and documented but still open (i.e. not addressed yet) and so the documentation of the findings in the initial analysis doesn't get lost and people need to start from scratch again. As I said, I reached out already to another person and asked to help to fix this in ADS now.

I'm not sure how you determine the usage statistics for your library which allows you to say how many users you have on which platform, but the number of bug reports is also considered as an indicator for the usage and for how willing the users are to report (and not to ignore/accept) such issues. It doesn't automatically mean these users are able to fix those issues, though. The current two open pull requests (727 and 664) seem to be from linux users. I wouldn't generalize too much describing a big open-source community, especially not using such terminology as "linux sucks", etc., based on the selective perception and experience of one single project.

Our team, mostly linux developers and users, did already two smaller contributions to ADS last year and we have a couple of more improvements and fixes that we planned to push soon, mostly for the issues reported during the last Coverity scan for LabPlot (for the internal copy of ADS that we use in LabPlot). We'll also help with the issue on Wayland (Wayland it's not "esoteric"). So, let's please calm down and return back to the constructive communication and working style.

In Ubuntu 24.04 with Qt 6.5+, when using the NVIDIA driver, the XDG_SESSION_TYPE environment variable is set to x11, and everything works fine. However, when using the X.Org X Server with the Nouveau display driver, XDG_SESSION_TYPE is set to wayland, requiring me to manually set the QT_QPA_PLATFORM environment variable to xcb for proper functionality.

As a temporary workaround until submit a PR, I decided to add the following lines right after defining the main() function:

qputenv("XDG_SESSION_TYPE", "wayland");
qputenv("QT_QPA_PLATFORM", "xcb");

This ensures that the application runs correctly regardless of the display driver in use.

[ciros88]

same issue here, temporary solved as following (based on @jafarabadi workaround):

int main(int argc, char *argv[]) {
#ifndef WIN32
    // TODO temp workaround for qt-ads on wayland https://github.com/githubuser0xFFFF/Qt-Advanced-Docking-System/issues/714
    if (comparesEqual(qEnvironmentVariable("XDG_SESSION_TYPE"), "wayland")) {
        qputenv("QT_QPA_PLATFORM", "xcb");
    }
#endif

    QApplication a(argc, argv);
    MainWindow w(argc, argv);
    return a.exec();
}

[asemke]

@ciros88 in case your application is also available for macOS, you don't need to have that if and qputenv on macOS. The way how we did the workaround was https://invent.kde.org/education/labplot/-/merge_requests/675/diffs (XDG_SESSION_TYPE is not always available, neither).