Created attachment 178221 [details] System tray glitches SUMMARY Graphical glitches occur when the information pop-ups are displayed while hovering over system tray icons. STEPS TO REPRODUCE Hover the mouse over system tray icons and wait for the details to appear. OBSERVED RESULT The attached video illustrates two examples: 1. When hovering over the color picker widget, the text glitches, as if multiple pop-ups were trying to appear simultaneously. 2. The pop-up for the battery widget blinks one time before being displayed. I have also noticed this issue with the media player and notification widgets, but it may affect other widgets as well. EXPECTED RESULT Pop-ups should appear smoothly without glitches or flickering. SOFTWARE/OS VERSIONS OS: Fedora 41 KDE Plasma Version: 6.3.0 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.2 ADDITIONAL INFORMATION I observed this issue both in multi-monitor setups with different scaling factors (1 and 2) and on a single monitor with scaling set to 2. This bug has been present on my system for some time and is not new to KDE 6.3.
I was able to reproduce both issues on 6.3.0 and git-master
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kdeplasma-addons/-/merge_requests/677
The other glitches seem to be from the tooltip changing size - the larger contents are pushed up (or in my testing sometimes down), before the tooltip dialog itself grows, and then things snap into the correct place. This can get rendered in the meantime, so you get unpleasant jumps. Not sure how to best fix this. The specific weirdness with the color picker should be taken care of with the above MR.
Git commit fae8cfce308ada57a8dc557460386b437a15a0af by Christoph Wolk. Committed on 18/02/2025 at 05:45. Pushed by cwo into branch 'master'. applets/colorpicker: fix tooltips Colorpicker sets custom tooltips for its buttons (pick and color value). However, these do no actually work while they are in a panel, only while the fullRepresentation popup is open. This is because the automatic tooltip generation from the compactRepresentation loader kicks in, sees that the plasmoid's own tooltip values are null, and "helpfully" replaces the intended custom values with default ones. Due to the specific timing involved with the multiple stacked ToolTipAreas, there is also a visual glitch as the user moves the mouse over the applet, where the intended content can briefly flash in for a fraction of a second. Instead, set the plasmoid's thumbnail main and sub text to empty string; this prevents the automatic assignment of a default tooltip and resolves the glitchy appearance. M +3 -0 applets/colorpicker/package/contents/ui/main.qml https://invent.kde.org/plasma/kdeplasma-addons/-/commit/fae8cfce308ada57a8dc557460386b437a15a0af
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kdeplasma-addons/-/merge_requests/679
Git commit 6456c6f8aa1a2c6d79dd61fe23d280f3380ef3c8 by Christoph Wolk. Committed on 18/02/2025 at 10:04. Pushed by cwo into branch 'Plasma/6.3'. applets/colorpicker: fix tooltips Colorpicker sets custom tooltips for its buttons (pick and color value). However, these do no actually work while they are in a panel, only while the fullRepresentation popup is open. This is because the automatic tooltip generation from the compactRepresentation loader kicks in, sees that the plasmoid's own tooltip values are null, and "helpfully" replaces the intended custom values with default ones. Due to the specific timing involved with the multiple stacked ToolTipAreas, there is also a visual glitch as the user moves the mouse over the applet, where the intended content can briefly flash in for a fraction of a second. Instead, set the plasmoid's thumbnail main and sub text to empty string; this prevents the automatic assignment of a default tooltip and resolves the glitchy appearance. (cherry picked from commit fae8cfce308ada57a8dc557460386b437a15a0af) Co-authored-by: Christoph Wolk <cwo.kde@posteo.net> M +3 -0 applets/colorpicker/package/contents/ui/main.qml https://invent.kde.org/plasma/kdeplasma-addons/-/commit/6456c6f8aa1a2c6d79dd61fe23d280f3380ef3c8
The other issues are not really fixable without a transition between them, which was explicitly removed because it caused even worse glitches. So for now let's call this fixed in Plasma 6.3.1, at least to the extent we can fix it.
Created attachment 178557 [details] four consecutive frames from a screen recording (In reply to Nate Graham from comment #7) > The other issues are not really fixable without a transition between them, > which was explicitly removed because it caused even worse glitches. Are you sure that's the only way? The content gets updated before the size of the popup, which causes much of the glitchy look. Going back to morphing popups is probably a bad idea, but if we can go from content updates, gets painted in the wrong spot as there's not enough space -> popup size updates, gets painted -> content gets painted correctly to content updates does not get painted yet -> popup size updates -> content gets painted correctly it should look a lot cleaner, even if the popup might appear a frame later. And without having attempted it (but having looked at that area of the code recently) I think it should be possible - we could intercept the maintext/subtext changes, calculate or at least approximate the size, then set the item's implicit sizes before actually putting the content in. It won't be quite as smooth as morphing popups was in the cases when it worked, but just avoiding things like in the screenshot should make it look much better. I think it at least could work, unless I'm missing something.
I gave it a try with https://invent.kde.org/plasma/libplasma/-/merge_requests/1269
Turns out that we can improve the situation a bit with some trickery. (So my idea was right at least!) But as it turns out, it soon won't be necessary, as Qt 6.9 will be much better in this regard. I tried it out on one of my computers and it's smooth as-is, without any further changes like the ones I implemented. This will be released in a month or two, and should improve the situation a lot once it makes it into distributions. So let's leave this issue at fixed and wait for the final parts to arrive from upstream.