https://bugs.kde.org/show_bug.cgi?id=389448
--- Comment #19 from Andrew Hou <andrewf...@gmail.com> --- Spent some time digging into it, and this is what I came up with regarding this bug: The issue appears to happen whenever windows scaling of Plasma is set to something greater than 1 on a high dpi monitor. Yakuake will generate its initial dimensions based off of the original, unscaled dpi. This is accurate to observations of various testing on a high dpi system This is why Yakuake isn't centered on the screen: Yakuake specifies its own width via percentage of the max width of the screen, but it does so before the dpi is scaled. The issue seems to be reliably solved when a new virtual desktop is generated and Yakuake is reopened in it. Somehow, this generation forces Yakuake to recalculate the screen width in accordance to the scaled values. getDesktopGeometry() at yakuake/app/mainwindow.cpp:1435 seems to be where Yakuake is getting the information used to determine its dimensions. For non-Wayland and non-fullscreen, KWindowSystem::workArea() in kwindowsystem.cpp:601 is being called, which appears to then call devicePixelRatio() I believe this is the reason why the bug occurs: devicePixelRatio(), from the QGuiApplication class simply gets the HIGHEST screen device pixel ratio found on the system. We need to somehow programmatically determine the user's specified display/monitor scaling, and apply this in KwindowSystem::workArea() This can potentially done by using QWindow::devicePixelRatio() instead of QGuiApplication::devicePixelRatio(), as the QWindow variant specifically gets the pixel ratio for the specified window, which should respect the system's dpi scaling. I suspect that the creation of a virtual desktop on Plasma forces a re-calculation of devicePixelRatio(), potentially being called from QWindow, which is why the Yakuake window is 'fixed' when generating a new Plasma desktop. This is all speculation, however. -- You are receiving this mail because: You are watching all bug changes.
