SUMMARY On wayland certain parts of Lokalize main window don't repaint. For example after scrolling in the list of strings there is an area that doesn't change. Or clicking on a string should show the original and the translation on the right side but only one of the fields gets updated. Usually hovering over the affected area, clicking in the area, switching to a different app and other actions force the repaint. Forcing Lokalize to use XWayland fixes this issue. SOFTWARE/OS VERSIONS KDE Plasma Version: 5.19.3 KDE Frameworks Version: 5.71 Qt Version: 5.15.0 This report might belong to Kwin bugs.
Can you please run lokalize as `env WAYLAND_DEBUG=1 lokalize` and post the output here?
Created attachment 130430 [details] Log
The symptoms sound similar to drkonqi bug 418755/420035 which was the result of an application bug creating accidental windows randomly for non-toplevel QWidgets.
Gammaray implies it's the same thing as above. There are a bunch of QWidgetWindow objects children of the toplevel QWidgetWindow. There should only be one for each actual window. This is an application bug. Can you give steps from a clean install and no config to reproduce this issue?
I'm debugging blind a bit, but it seems we have multiple TMTab objects that (indirectly) inherit from KMainWindow despite being children. kmainwindow.cpp will force creation of a platform window, which makes sense for a toplevel, but otherwise will cause the problems above. 349 q->winId(); // workaround for setWindowRole() crashing, and set also window role, just in case TT This should hopefully be fixable if we add some sort of "if (q->isWindow())" round this code.
(In reply to David Edmundson from comment #4) > Can you give steps from a clean install and no config to reproduce this > issue? 1. (create a new user) 2. start Lokalize 3. open a .po file 4. try to scroll in the "list of strings" -> it doesn't move or try resizing one of the sub-windows -> it leaves a trail
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kxmlgui/-/merge_requests/21
Git commit 03b0f4c333c688059645846563e7795772e62bfe by Albert Astals Cid, on behalf of David Edmundson. Committed on 29/09/2020 at 22:34. Pushed by davidedmundson into branch 'master'. [kmainwindow] Don't create native windows for non-toplevel windows winId() creates a QPlaformWindow; i.e a native xcb_window or wl_surface. This makes sense for a toplevel which will be a real window. If someone (in this case localize) uses kmainwindow as a subwidget inside an existing window the current code will create a subwindow for this widget. It's a very weird window, as the window is never actually mapped so all contents are drawn as part of the parent window. Leaving us in a very corrupt state. Doing this on XCB is wasteful but the side effects are unnoticed. On QtWayland things explode in weird ways. M +5 -3 src/kmainwindow.cpp https://invent.kde.org/frameworks/kxmlgui/commit/03b0f4c333c688059645846563e7795772e62bfe
I am on Arch Linux, Lokalize 20.12, everything else also up-to-date and I still have this issue. Can someone confirm either way?
I can confirm that the issue is still present in Lokalize 20.12.2 (Qt 5.15.2, KDE Neon User). This unfortunately makes Lokalize basically unusable on Wayland.
Could you please look at it again? The modifications in kxmlgui didn't fix the issue with Lokalize. Enforcing XWayland by adding `-platform xcb` is good a workaround for the meantime if you don't want to go back to X11 completely.
The problem persists in Lokalize 21.04.0
Put a breakpoint on QPlatformWindow::QPlatormWindow it should occur once for the top level and again for menus, any others are your source of problems
typo Platorm QPlatformWindow::QPlatformWindow would be correct
It occurs fairly often in fact, about 45 breakpoints until the main window turns up.
However, I'm not sure whether this is the right approach. This is not one of the classical Qt/Wayland rendering issues; and no breakpoint happens when the window doesn't repaint properly.
(In reply to David Edmundson from comment #13) > Put a breakpoint on QPlatformWindow::QPlatormWindow > > it should occur once for the top level and again for menus, any others are > your source of problems I suggest that you, the developers, could make the backtracing on your own rather than asking unskilled users (who can't understand the output) to do it. This issue is easy to reproduce after all.
needs a trace to be Probably fixed with my commit above, it was reopened without confirming frameworks version. if it's not please add backtrace as requested.
I don't know if there's a misunderstanding, but the commit you referenced is one year old and therefore should already have been released to end users, right? As the obvious visual problems still persist, I believe your commit did not fix the issue. (Software versions: KDE Frameworks 5.88 and kxmlgui 5.87.0+build37 in Neon User)
(In reply to geisserml from comment #19) > (Software versions: KDE Frameworks 5.88 and kxmlgui 5.87.0+build37 in Neon User ... however, now I come to think about this, it's really strange that system settings report Frameworks 5.88 and most kf5 package versions have something with 5.88, but libkf5xmlgui5 is still at 5.87 - is this an issue with Neon Packages? Is the fix part of KF5 5.87 already, or not?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
@davidedmundson Repeating the question: Is your supposed fix part of the kxmlgui release that is currently in KDE Neon User? If yes, then it clearly didn't fix the issue. If not, we need to update kxmlgui and then check again.
So today kxmlgui got updated to 5.89 in Neon User. Your commit unfortunately does not fix the issue. Please investigate the true cause.
I'm seeing this too, on Kubuntu 21.10 with Plasma 5.24.3 an Frameworks 5.89. Is there any additional helpful data that I can provide?
*** Bug 445887 has been marked as a duplicate of this bug. ***
Same problem on Arch Linux, KDE Plasma 5.26.4, Wayland. Repo or Flatpak version does not matter. Guys, PLEASE fix this. I can't use this program with so many UI glitches...
*** This bug has been confirmed by popular vote. ***
*** Bug 462485 has been marked as a duplicate of this bug. ***
I just ran localize with my steps above: #0 0x00007ffff1883720 in QtWaylandClient::QWaylandWindow::QWaylandWindow(QWindow*, QtWaylandClient::QWaylandDisplay*) () from /opt/qt5/lib/libQt5WaylandClient.so.5 #1 0x00007ffff69dfa02 in ?? () from /opt/qt5/plugins/wayland-graphics-integration-client/libqt-plugin-wayland-egl.so #2 0x00007ffff69dded7 in ?? () from /opt/qt5/plugins/wayland-graphics-integration-client/libqt-plugin-wayland-egl.so #3 0x00007ffff1871e1a in QtWaylandClient::QWaylandIntegration::createPlatformWindow(QWindow*) const () from /opt/qt5/lib/libQt5WaylandClient.so.5 #4 0x00007ffff5584aeb in QWindowPrivate::create (this=0x555556f526b0, recursive=false, nativeHandle=0) at /home/david/projects/kde5/src/Qt5/qtbase/src/gui/kernel/qwindow.cpp:528 #5 0x00007ffff5583ac8 in QWindow::create (this=0x555556fe3f10) at /home/david/projects/kde5/src/Qt5/qtbase/src/gui/kernel/qwindow.cpp:657 #6 0x00007ffff5fd1852 in QWidgetPrivate::create (this=0x555555b16030) at /home/david/projects/kde5/src/Qt5/qtbase/src/widgets/kernel/qwidget.cpp:1316 #7 0x00007ffff5fcfed7 in QWidget::create (this=0x555555fac280, window=0, initializeWindow=true, destroyOldWindow=true) at /home/david/projects/kde5/src/Qt5/qtbase/src/widgets/kernel/qwidget.cpp:1181 #8 0x00007ffff5fd11ba in QWidgetPrivate::createWinId (this=0x555555b16030) at /home/david/projects/kde5/src/Qt5/qtbase/src/widgets/kernel/qwidget.cpp:2384 #9 0x00007ffff5fcf8de in QWidget::setAttribute (this=0x555555fac280, attribute=Qt::WA_NativeWindow, on=true) at /home/david/projects/kde5/src/Qt5/qtbase/src/widgets/kernel/qwidget.cpp:11059 #10 0x00007ffff5fd10e2 in QWidgetPrivate::createWinId (this=0x555555aab0f0) at /home/david/projects/kde5/src/Qt5/qtbase/src/widgets/kernel/qwidget.cpp:2375 #11 0x00007ffff5fcf8de in QWidget::setAttribute (this=0x555555aaad00, attribute=Qt::WA_NativeWindow, on=true) at /home/david/projects/kde5/src/Qt5/qtbase/src/widgets/kernel/qwidget.cpp:11059 #12 0x00007ffff5fd10e2 in QWidgetPrivate::createWinId (this=0x55555708cb10) at /home/david/projects/kde5/src/Qt5/qtbase/src/widgets/kernel/qwidget.cpp:2375 #13 0x00007ffff5fd10fe in QWidgetPrivate::createWinId (this=0x555556aacf10) at /home/david/projects/kde5/src/Qt5/qtbase/src/widgets/kernel/qwidget.cpp:2377 #14 0x00007ffff5fd1012 in QWidget::createWinId (this=0x555556aecb10) at /home/david/projects/kde5/src/Qt5/qtbase/src/widgets/kernel/qwidget.cpp:2444 #15 0x00007ffff5fed05c in QWidgetPrivate::setParent_sys (this=0x555556aacf10, newparent=0x555556cbb050, f=...) at /home/david/projects/kde5/src/Qt5/qtbase/src/widgets/kernel/qwidget.cpp:10633 #16 0x00007ffff5fd04c1 in QWidget::setParent (this=0x555556aecb10, parent=0x555556cbb050, f=...) at /home/david/projects/kde5/src/Qt5/qtbase/src/widgets/kernel/qwidget.cpp:10443 #17 0x00007ffff5fec89c in QWidget::setParent (this=0x555556aecb10, parent=0x555556cbb050) at /home/david/projects/kde5/src/Qt5/qtbase/src/widgets/kernel/qwidget.cpp:10366 #18 0x00007ffff5fbdc80 in QLayout::addChildWidget (this=0x555556d1f690, w=0x555556aecb10) at /home/david/projects/kde5/src/Qt5/qtbase/src/widgets/kernel/qlayout.cpp:926 #19 0x00007ffff5fbd941 in QLayout::addWidget (this=0x555556d1f690, w=0x555556aecb10) at /home/david/projects/kde5/src/Qt5/qtbase/src/widgets/kernel/qlayout.cpp:235 #20 0x00007ffff61b9b80 in QMdiSubWindow::setWidget (this=0x555556cbb050, widget=0x555556aecb10) at /home/david/projects/kde5/src/Qt5/qtbase/src/widgets/widgets/qmdisubwindow.cpp:2312 #21 0x00007ffff61a5675 in QMdiArea::addSubWindow (this=0x555555fac280, widget=0x555556aecb10, windowFlags=...) at /home/david/projects/kde5/src/Qt5/qtbase/src/widgets/widgets/qmdiarea.cpp:1987 #22 0x00005555555dda13 in LokalizeMainWindow::fileOpen (this=0x5555558cce40, filePath=..., entry=0, setAsActive=true, mergeFile=..., silent=false) at /home/david/projects/kde5/src/kde/kdesdk/lokalize/src/lokalizemainwindow.cpp:262 #23 0x00005555555c4cc1 in LokalizeMainWindow::qt_static_metacall (_o=0x5555558cce40, _c=QMetaObject::InvokeMetaMethod, _id=33, _a=0x7fffffffaad0) at src/liblokalize_autogen/EWIEGA46WW/moc_lokalizemainwindow.cpp:288 here's our problem.
The editor window we're embedding into a subwindow is a subclass of KMainWindow. As soon as the backend things we're embedding windows in windows, but client code thinks it's embedding widgets in widgets it all gets out of sync.
Problem is still here. Arch Linux, plasma 5.27, frameworks 103, Lokalize 22.12.2.
I just found that on Kubuntu 22.10 the XCB workaround is also completely broken, just making the file tab all black. Wayland problem is still present. (In reply to David Edmundson from comment #5) > I'm debugging blind a bit, but it seems we have multiple TMTab objects that > (indirectly) inherit from KMainWindow despite being children. I think you are right, see https://invent.kde.org/sdk/lokalize/-/blob/master/DESIGN: > Tabs are KMainWindows + KXmlGuiCleints. Given that workarounds are not really working, I guess the application code should be modified.
Bug still present at my setup: lokalize-23.04.0-1.fc37.x86_64 Operating System: Fedora Linux 37 KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.105.0 Qt Version: 5.15.9 Kernel Version: 6.2.15-200.fc37.x86_64 (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-3632QM CPU @ 2.20GHz Memory: 15.4 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 4000 kf5-kwindowsystem-5.105.0-1.fc37.x86_64 kf5-kxmlgui-5.105.0-1.fc37.x86_64 kwin-libs-5.27.5-1.fc37.x86_64 kwin-common-5.27.5-1.fc37.x86_64 kwin-x11-5.27.5-1.fc37.x86_64 kwin-wayland-5.27.5-1.fc37.x86_64 kwin-5.27.5-1.fc37.x86_64
Created attachment 158875 [details] workaround is fine for now Added ´´-platform xcb´´ to the launcher at menu edit and its correctly using xwayland without problems on fedora 37 KDE spin. Its a workaround indeed.
Still present on openSUSE Tumbleweed with KDE Plasma 5.27. -platform xcb is a good workaround, but really shouldn't be needed, especially now that KDE is so focused on Wayland.
(In reply to Geraldo Simião from comment #34) > Created attachment 158875 [details] > workaround is fine for now > > Added ´´-platform xcb´´ to the launcher at menu edit and its correctly using > xwayland without problems on fedora 37 KDE spin. > Its a workaround indeed. Problem is still here, but this workaround works for me, great!
It used to work with the workaround, as I reported last month, but somewhere in the past few weeks, it stopped working. Still openSUSE Tumbleweed with Plasma 5.27.
You need to set QT_QPA_PLATFORM=xcb for Lokalize, then it works. In Edit app->App->Environment variables.
(In reply to Matej Mrenica from comment #38) > You need to set QT_QPA_PLATFORM=xcb for Lokalize, then it works. In Edit > app->App->Environment variables. I have done that and like I said, it used to work, but it stopped working for me.
Is https://bugs.kde.org/show_bug.cgi?id=456908 a duplicate of this?
I use Lokalize 22.12.3 (KDE env 5.103.0 and Qt 5.15.8) on Debian 12 stable with GNOME and Wayland, and I have the same bug. Add the argument `-platform xcb` have solved also the problem, but it was not easy to go here to find the solution
“QT_QPA_PLATFORM=xbc lokalize” did not work. “env -u DISPLAY_WAYLAND lokalize” did not work either (idea from https://www.reddit.com/r/swaywm/comments/jivv8n/comment/ga90583/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button). No idea where to set “-platform xbc”, but I am guessing that if the options above did not work this one will not help either. Feels like with or without XWayland, Localize repaints poorly in a Wayland session. Having X11 in Plasma 6 seems like it is not an option (based on https://fedoraproject.org/wiki/Changes/KDE_Plasma_6#Feedback). I‘m sad.
Still having this issue as well. I'm waiting for Plasma 6 and all of its apps to land on Tumbleweed, but I'm not holding my breath for this to be actually fixed.
After Plasma 6.0 upgrade, I removed the environment variable. It seems that the problem has been fixed.
I am on an up-to-date Arch Linux, and the last upgrade brought Plasma 6 in and forced Wayland, which is how I found out about this issue with Lokalize.
(In reply to Adrián Chaves (Gallaecio) from comment #42) > “QT_QPA_PLATFORM=xbc lokalize” did not work. > “env -u DISPLAY_WAYLAND lokalize” did not work either (idea from > https://www.reddit.com/r/swaywm/comments/jivv8n/comment/ga90583/ > ?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=s > hare_button). > No idea where to set “-platform xbc”, but I am guessing that if the options > above did not work this one will not help either. Feels like with or without > XWayland, Localize repaints poorly in a Wayland session. > Having X11 in Plasma 6 seems like it is not an option (based on > https://fedoraproject.org/wiki/Changes/KDE_Plasma_6#Feedback). > I‘m sad. First, be sure that you try `QT_QPA_PLATFORM=xcb lokalize` and not `QT_QPA_PLATFORM=xbc lokalize` It works on my machine™ (Debian 12 Gnome). If it works, you can also add the line `export QT_QPA_PLATFORM=xcb` at the start of your `.profile` file. Another option is to edit your lokalize's desktop file to run `QT_QPA_PLATFORM=xcb lokalize` rather than just `lokalize` (for this, DuckDuckGo is your friend !). If it doesn't work, try to launch `lokalize -platform xcb` rather than just `lokalize`. Hope this help.
(In reply to Adrián Chaves (Gallaecio) from comment #45) > I am on an up-to-date Arch Linux, and the last upgrade brought Plasma 6 in > and forced Wayland, which is how I found out about this issue with Lokalize. Yes, you're right. It seems I still have something forcing xcb for lokalize. Be aware that the right platform is xcb not xbc.
Using “QT_QPA_PLATFORM=xcb lokalize” or “lokalize -platform xcb” does not make a difference to me, the behavior is the same as with plain “lokalize”, where eventually something does not repaint. In fact, it’s a bit weirder than “does not repaint”, it is like a constant, ~1-second flickering between 2 painting states, some old one, and the one that should be. I tried to record this with OBS Studio. But I couldn’t. It turns out, while OBS Studio is recording, the issue does not happen. It feels like OBS Studio forces the latest, right painting. It’s a nasty workaround, but it beats the months it would take me to fix this issue myself.