SUMMARY Context menus will "scale in" the same way windows do with the "Scale" Desktop Effect enabled. Previously, they would immediately appear. This also affects Global Menu dropdowns, but it is inconsistent and only happens if you mouse over different tabs of the Global Menu quickly. Note that this is separate to what is present with what I believe are QtQuick applications, which have always had different context menu behaviour to the rest of the system. STEPS TO REPRODUCE Dolphin is being used in this example, but it is not the only example. 1. Right-click anywhere in Dolphin 2. The context menu "scales in" instead of instantly appearing as in previous Plasma releases. OBSERVED RESULT Context menus have a "scale in" animation instead of instantly appearing. EXPECTED RESULT Context menus should instantly appear and not be animated unless configured to do so. I believe there is a "Fade" effect that one can apply, but I do not have this enabled, and that is different to this behaviour where context menus are taking on the effect that would normally be applied to windows. SOFTWARE/OS VERSIONS KDE Plasma Version: 6.3.0 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.2 Graphics Platform: Wayland ADDITIONAL INFORMATION This mirrors the buggy behaviour of the Steam application under XWayland, where its context menus have similar behaviour. But this is now present for regular Wayland Qt applications under Plasma 6.3.0.
Please post the output of qdbus org.kde.KWin /KWin supportInformation
Can confirm Operating System: Arch Linux KDE Plasma Version: 6.3.0 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.2 Kernel Version: 6.13.2-2-cachyos (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 9800X3D 8-Core Processor Memory: 62.5 ГиБ of RAM Graphics Processor: AMD Radeon RX 6700 XT Manufacturer: ASUS
Created attachment 178303 [details] kwin support information Here's mine
I enabled the same effects but popups are still animated as expected.
Huh, now that I changed effects a couple of times they're now animated as supposed with "fade in/fade out". Previously popups would have "scale in" animation for me as well.
(In reply to Oleg from comment #5) > Huh, now that I changed effects a couple of times they're now animated as > supposed with "fade in/fade out". Previously popups would have "scale in" > animation for me as well. Even after rebooting the computer?
I will attach my KWin information after posting this comment, thanks for the direction! > I enabled the same effects but popups are still animated as expected. For the record, any animated behaviour is unexpected on my setup. Popups should not fade, or scale. Since opening this issue I have also noticed that this affects some system tooltips (independent of the ones in some I believe QtQuick applications), but inconsistently. Tooltips on panels seem to do it consistently, but inside of applications (i.e. Firefox) it is inconsistent.
Created attachment 178326 [details] KWin QDbus Information
(In reply to Eamonn Rea from comment #7) > I will attach my KWin information after posting this comment, thanks for the > direction! > > > I enabled the same effects but popups are still animated as expected. > > For the record, any animated behaviour is unexpected on my setup. Popups > should not fade, or scale. > > Since opening this issue I have also noticed that this affects some system > tooltips (independent of the ones in some I believe QtQuick applications), > but inconsistently. Tooltips on panels seem to do it consistently, but > inside of applications (i.e. Firefox) it is inconsistent. If you enable the fading popups effect, they are not scaled anymore, right?
Ah, yes, correct. If I enable the Fade effect, this stops the scale issue described in this ticket. Disabling "Fade" resumes the scale behaviour described here :-)
Okay, I think i know what's going on. It's connected to the fractional scaling changes.
Wow, I am so sorry, I didn't even think to check my non-scaled displays. Now that you have mentioned it, I can add this issue does not happen on unscaled displays.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/7150
Git commit 78cb68b655d42cb8728ada17178e0f521c2f3f86 by Vlad Zahorodnii. Committed on 14/02/2025 at 01:44. Pushed by vladz into branch 'master'. effect: Fix EffectWindow::hasDecoration() The fractional part in the width() and the height() is truncated by the QRect(). This makes the hasDecoration() function return true for popups with fractional scaling. The scale effect checks whether a window has a decoration to determine whether it can be animated. The issue can be resolved by changing the QRect to a QRectF but a more robust way to fix the bug is to inspect the Window::decoration property. M +1 -1 src/effect/effectwindow.cpp https://invent.kde.org/plasma/kwin/-/commit/78cb68b655d42cb8728ada17178e0f521c2f3f86
Git commit 6e34985182f9e47772796cbc6e903f3f77dc5141 by Vlad Zahorodnii. Committed on 14/02/2025 at 02:17. Pushed by vladz into branch 'Plasma/6.3'. effect: Fix EffectWindow::hasDecoration() The fractional part in the width() and the height() is truncated by the QRect(). This makes the hasDecoration() function return true for popups with fractional scaling. The scale effect checks whether a window has a decoration to determine whether it can be animated. The issue can be resolved by changing the QRect to a QRectF but a more robust way to fix the bug is to inspect the Window::decoration property. (cherry picked from commit 78cb68b655d42cb8728ada17178e0f521c2f3f86) Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org> M +1 -1 src/effect/effectwindow.cpp https://invent.kde.org/plasma/kwin/-/commit/6e34985182f9e47772796cbc6e903f3f77dc5141
In addition to fixing the bug as described in this report, this appears to have also fixed the long-standing issue of this happening on XWayland applications as well (most notably, Steam)!!!! Awesome stuff, thank you so much :-)