githubuser0xFFFF
Support floating docks on Wayland
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 https://github.com/githubuser0xFFFF/Qt-Advanced-Docking-System/issues/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.
Thank you for reporting this issue. I will not fix this but you can provide a pull request
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.
Deletion of comments - is this your understanding of the open-source philosophy?
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?
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.
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();
}
@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).
Given that Qt (from what I understand) does support drag-and-drop in Wayland, there should be solution for a Wayland-only approach. I'm currently trying to dig into the matter to understand what's actually going on here. For now all the signs points to QDrag and QDrag*Event, which makes it a bit baffling that it's in a broken state. Somehow, the end of the drag-and-drop isn't picked up, even if nothing is dragged outside the window area. That could just be a symptom of a deeper problem
@githubuser0xFFFF I understand you're not developing for Linux, but do you despite that have an understanding of how this works in X11 context? I can't promise I'll fix this, but some pointers might help me (or someone else for that matter) progress with this issue.
@AHSauge the relevant information was provided in https://invent.kde.org/education/labplot/-/issues/1067#note_1128693 by the person who implemented (or contributed to) the support for Wayland in QDockWidget in Qt.
@AHSauge the relevant information was provided in https://invent.kde.org/education/labplot/-/issues/1067#note_1128693 by the person who implemented (or contributed to) the support for Wayland in QDockWidget in Qt.
That's far from all relevant information. The problem isn't the magic mime stuff (which it gives good pointers on), but rather that I need to understand which widget is actually the window to drag around, and then extract the window handle for it. Right now I'm ending up initiating a drag on the main window instead of the floating widget. So initiating a drag-and-drop isn't the problem right now
@AHSauge the relevant information was provided in https://invent.kde.org/education/labplot/-/issues/1067#note_1128693 by the person who implemented (or contributed to) the support for Wayland in QDockWidget in Qt.
That's far from all relevant information. The problem isn't the magic mime stuff (which it gives good pointers on), but rather that I need to understand which widget is actually the window to drag around, and then extract the window handle for it. Right now I'm ending up initiating a drag on the main window instead of the floating widget. So initiating a drag-and-drop isn't the problem right now
In your previous comment you asked about X11. This issue here as well as the issue on KDE's gitlab instance that I referred to is about Wayland, not about X11. https://github.com/Sodivad/ is looking into this problem now.
Hi, I faced the same issue when testing on Ubuntu 22.04 (virtualbox) an app that I mostly developed on windows. I use PySide 6.9.0 + QTAds 4.4.0. The workaround also worked for me, but I had to manually install libxcb-cursor0 though
@AHSauge : I understand that you might be looking into this. If you decide to let go, please report it here. I'd like to know.
I know nothing about rendering engine and X11/Wayland, but if nobody looks into it, I might as well start digging (eventually, Linux support is not a priority for me).
Cheers
@AHSauge : I understand that you might be looking into this. If you decide to let go, please report it here. I'd like to know. I know nothing about rendering engine and X11/Wayland, but if nobody looks into it, I might as well start digging (eventually, Linux support is not a priority for me).
Cheers
I've been a bit too pre-occupied to dive more into this, so no change. I'm able to initiate drag for the main window, which obviously isn't what we want, but also feels quite close to solving the bulk of the problem. That said, depending on how this is structured underneath, it might be that the tab needs to be prematurely detached to have a separate window handle that can be dragged around.
I'm not sure when I'd have some time to really sit down and have another look at this. Potentially during the upcoming weekend, but I might also just be busy with other things, so no promises.