wxDataViewChoiceRenderer placement and visual bug on Linux (Issue #26021)
Legiaoday
Legiaoday created an issue (wxWidgets/wxWidgets#26021)Bug description:
Clicking on a wxDataViewChoiceRenderer to bring up the dropdown list makes the list appear at the top left of the parent dataview.
Expected vs observed behaviour:
The dropdown list should be appearing right on top of the wxDataViewChoiceRenderer control that was clicked instead of the top left corner of the parent dataview. A translucent 'ghost' of the choice control that was clicked also appears right on top of its current position. Technically, the control is still usable in this broken state, but it looks terrible and is pretty confusing.
Here's a video of the issue.
To Reproduce:
The issue is easy to reproduce with the default unmodified 'dataview' sample:
- Open the dataview sample, maximize it and make sure the 'MyMusicTreeModel' tab is selected.
- Keep clicking on the 'Add Mozart' button until there's enough rows to make the scrollbar on the right appear.
- Under the 'Rating' column, select a wxDataViewChoiceRenderer (that by default says 'good') and then left mouse click on it to bring up the dropdown list with the available options.
Following these steps will cause the bug to happen about 2/3 of the time according to my tests. Technically, the bug can happen when the dataview only has one row and no scrollbar is present, but from my tests it's really rare, maybe a 1/100 chance.
Very important considerations:
The system where this issue is happening is an Arch Linux running KDE Plasma and Wayland. But did perform some tests on a different system running Linux Mint with Cinnamon and X11, and the issue DID NOT manifest on that other system, not even once. Which might suggest the issue might be caused by either the desktop environment or display server of my Arch system. I'm not sure.
I also tested a few different wxWidgets versions on both systems. Bellow are more detailed info on that.
Platform and version information (system where the bug DOES happen)
- Distro: Arch Linux
- Linux Kernel Version: 6.17.5
- wxWidgets versions tested: 3.2.8 and 3.3.2. (built from the latest GitHub master source).
- KDE Plasma Version: 6.5.1
- KDE Frameworks Version: 6.19.0
- KDE Plasma Theme: Breeze Dark
- Wayland Package Version: 1.24.0-1
- GTK3 Version: 3.24.51
- GTK4 Version: 4.20.2
- Clang Version: 21.1.6
Platform and version information (system where the bug DOES NOT happen)
- Distro: Linux Mint
- Linux Kernel Version: 6.14.0-36-generic
- wxWidgets versions tested: 3.2.4 and 3.3.2. (built from the latest GitHub master source).
- Cinnamon Version: 6.4.8
- Cinnamon Theme: Mint-Y (Dark)
- X Protocol Version: 11.0
- X.Org Version: 21.1.11
- GTK3 Version: 3.24.41
- GTK4 Version: 4.14
- G++ Version: 13.3.0
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#26021)Thanks, I can reproduce this with a pretty different setup (Debian with Sway), so it's probably not specific to some particular GTK version or WM. Maximizing the window is not necessary to me, as soon as the scrollbar becomes needed (even though it is not visible, as overlay scrollbars are used), the bug shows up.
I didn't have time to debug this yet, however, unfortunately.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Legiaoday
Legiaoday left a comment (wxWidgets/wxWidgets#26021)Another detail that I completely forgot about (and you might be aware already) is that you can force a specific backend with GDK_BACKEND=. So, launching my application or the dataview sample with GDK_BACKEND=x11 in a Wayland session where the bug usually happens, will make the bug go away completely.
Although that environment variable forces your program to use XWayland, which is a compatibility layer that I'm not sure how close it is to the actual X11 server, I found it to be a pretty decent workaround. Of course, things running natively would be better, but I'm not gonna be picky.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.