STEPS TO REPRODUCE 1. open System Monitor on Wayland 2. maximize System Monitor window 3. restart System Monitor OBSERVED RESULT System Monitor occupies the whole screen but the button in window decoration indicates that its window is not maximized. EXPECTED RESULT System Monitor window should open maximized after the last step SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.21.90 KDE Frameworks Version: 5.82.0 Qt Version: 5.15.2 Graphics Platform: Wayland
Doesn't this affect every window?
(In reply to Nate Graham from comment #1) > Doesn't this affect every window? No. Dolphin, Konsole and Kate are not affected.
I tested on 5.21.90 and I can confirm that, but not only for System Monitor, the same occurs for other apps tested: Dolphin, System Settings, Discover... If the app is closed while maximized, the next time it will start restored (unmaximized) with the exact same size as it was when maximized, filling the entire screen. From that state, you can maximize and than restore again with no impact to the window dimensions. I think that the expected behavior is: - If an Window / Application closes while maximized, next time it should start maximized (state). - When a maximized window gets restored, it should be set for its last restored dimensions. - Which possible means that kwin (or the application) should save app's dimensions before it being maximized and than load that saved dimensions when the window is restored. - The saved window dimensions should persist between application sessions, as for its maximized / restored state. - When restoring window dimensions, it probably should be validated against the current screen/desktop size (which kwin already does, it seams).
I can reproduce this with every window, not just System Monitor. They get opened in the maximized position, but not the maximized state.
*** Bug 438262 has been marked as a duplicate of this bug. ***
*** Bug 438568 has been marked as a duplicate of this bug. ***
I think it happens on QT-applications only
I have two monitors and if I close application as maximized and open it than the application opens always on my left monitor. Totally ignores where is my cursor located. For example System Monitor will open on left monitor as maximized but not in maximized state. But Firefox opens in maximized state but if I click restore down than it will be still maximized but it switeches from maximized state to restore down state. Overall applications does not remember their positions and sizes.
*** Bug 444995 has been marked as a duplicate of this bug. ***
Still happened on 5.23.3 If application starts in maximized state, after dragging window, it is still in maximized state but "Restore" button has became "Maximize" button. And, click "Maximize" button, it doesn't work in the most time.
(In reply to s1994928 from comment #10) > If application starts in maximized state, after dragging window, it is still > in maximized state but "Restore" button has became "Maximize" button. > > And, click "Maximize" button, it doesn't work in the most time. reported as bug 444109
Clients should restore their maximized state if they also restore size.
I will move this to plasma-systemmonitor. For other apps we would need similiar reports and fixes
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-systemmonitor/-/merge_requests/175
I'm not sure that making every app fix this is the best idea. We can do it for KDE apps, but what about 3rd-party apps? IIRC KWin has a heuristic on X11 to maximize the window when it opens with a size equal to or greater than the maximized area; can't we do that on Wayland too?
I think that would be wrong, kwin tells the app to size itself how it wants and doesn't impose any state initially. Then the apps resizes itself to the maximized state but doesn't request maximized state.
The apps that save size are doing extra things compared to apps that do not save size. Imo if apps want to save size and have the same maximized state then they should also save maximized state
I have trouble believing this is something that needs to be resolved by individual apps. This effects various native Wayland applications, particularly Qt ones. I have experienced this with Dolphin, Konsole, MultiMC 5, Kate, Kalendar, System Settings, Discover, and several others, and also with VS Code running with relevant launch flags to use Ozone platform under Wayland.
(In reply to David Redondo from comment #17) > The apps that save size are doing extra things compared to apps that do not > save size. Imo if apps want to save size and have the same maximized state > then they should also save maximized state But if they don't (and they mostly won't; we already know this) then we have a difference in behavior between KDE apps and non-KDE apps that looks like a bug to the user. Especially because it's something that KWin is able to handle, and does handle on X11.
KWin is just doing what these apps request. I don't see this being an issue of KDE vs non-KDE apps. There is a new protocol addition proposed which could be used to solve this at an toolkit level https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/41
Since KWin does this on X11, it's not unreasonable for apps to expect the window manager to do it. Maybe KWin could do it until that work is merged?
Created attachment 148090 [details] video-recording-firefox-maximized-state
Hello, is this the right bug also for a new Firefox window created by "dragging out" a tab? Because if I drag out a tab from a maximized (both in size and button state) Firefox window, that tab is then shown in a new Firefox window which is maximized in terms of size, but not button state (it proposes to "maximize" while it already is). Video attached in previous comment. Operating System: openSUSE Tumbleweed 20220408 KDE Plasma Version: 5.24.4 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.2 Kernel Version: 5.17.1-1-default (64-bit) Graphics Platform: Wayland Processors: 8 × 11th Gen Intel® Core™ i7-1165G7 @ 2.80GHz Memory: 15,4 GiB of RAM Graphics Processor: Mesa Intel® Xe Graphics Thanks
*** Bug 455473 has been marked as a duplicate of this bug. ***
I can't reproduce this (anymore). Do you still have the issue on 5.25+? (In reply to andrea.ippo from comment #23) > Hello, > is this the right bug also for a new Firefox window created by "dragging > out" a tab? > Because if I drag out a tab from a maximized (both in size and button state) > Firefox window, that tab is then shown in a new Firefox window which is > maximized in terms of size, but not button state (it proposes to "maximize" > while it already is). No, the initial size of new windows is entirely up to Firefox.
> I can't reproduce this (anymore). Do you still have the issue on 5.25+? Using the steps in the OT, at least I can still reproduce it on Operating System: openSUSE Tumbleweed 20220702 KDE Plasma Version: 5.25.2 KDE Frameworks Version: 5.95.0 Qt Version: 5.15.5 Graphics Platform: Wayland Graphics Processor: AMD Radeon RX 580 Series
I can reproduce on neon unstable with System Monitor, desktop settings, settings of widgets on desktop and settings of applets/widgets present in Plasma panel (system tray, task manager, kickoff, media player, plasma-pa, digital clock). Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.25.80 KDE Frameworks Version: 5.96.0 Qt Version: 5.15.5 Graphics Platform: Wayland
*** Bug 434762 has been marked as a duplicate of this bug. ***
*** Bug 470010 has been marked as a duplicate of this bug. ***
Just chiming in to say this is still an issue, but only for some applications. For example, Dolphin behaves correctly and even restores to the right size, but System Monitor is affected, as is Elisa. GTK apps seem to handle this correctly on my Plasma Wayland desktop, at least Nautilus and Lutris do, although the latter doesn't remember the size to restore to.
*** Bug 473005 has been marked as a duplicate of this bug. ***
Anyone can confirm it's fixed in 5.27.8?
Not fixed; this requires one of two things to be done to fix it: 1. KWin interprets "open window at maximum size" to be equal to "open window in maximized state" on Wayland as it does on X11 2. All apps exhibiting this problem are changed to request opening in the maximized state rather than at the maximum window size So far KWin devs are not convinced that #1 is appropriate, and #2 has not been done yet even for KDE's own apps, so the problem is not fixed.
(In reply to Nate Graham from comment #33) > Not fixed; this requires one of two things to be done to fix it: > 1. KWin interprets "open window at maximum size" to be equal to "open window > in maximized state" on Wayland as it does on X11 > 2. All apps exhibiting this problem are changed to request opening in the > maximized state rather than at the maximum window size > > So far KWin devs are not convinced that #1 is appropriate, and #2 has not > been done yet even for KDE's own apps, so the problem is not fixed. I think 1. is sufficient because there is no meaning of maximize size without maximize state, i.e. no difference from user's perspective. Actually same applies to all other windows state like KWin positioning when touch edge 1/4, 1/2 i.e. when the size match a predefined state it should activate it. Actually there is (was) a problem in X11, (I'm not use it for few years) but when restart 1/2 window, it could start on its normal state (which is not 1/2 just random size), I investigate in the problem and came with conclusion especially difference between KWin sets normal state of the window which read from config its normal coordinates and size, but instead KWin should activate 1/2 state. In other hand the app (Kate) doesn't well store and read its state.
>So far KWin devs are not convinced that #1 is appropriate, This was rediscussed, with the same conclusion. #2 has not been done yet even for KDE's own apps, so the problem is not fixed. It has been done for KXmlGui. Other apps need relevant bugs filing on those applications
Git commit 27e0cce0bd0413e5a8c19af4413d29689b61812e by David Redondo. Committed on 12/12/2023 at 12:24. Pushed by davidre into branch 'master'. Save maximized state The hidden state is ignored to not overwrite when closing the window. The state is applied via initial properties because using a binding would create a loop and Component.onCompleted is to late. M +10 -0 src/Main.qml M +3 -0 src/main.cpp https://invent.kde.org/plasma/plasma-systemmonitor/-/commit/27e0cce0bd0413e5a8c19af4413d29689b61812e
Since this bug report has been closed on the basis that System Monitor is now fixed, I'll make it about System Monitor and un-dupe the other bug reports so they can be re-triaged and handled separately.
Also this is not truly fully fixed. System Monitor remembers that it was maximized, but it also inappropriately saves its new maximized geometry on quit, so when you unmaximize it, it fails to restore to the size it last had before being maximized. For that, I've opened Bug 478442.
If I understood correctly, every app is supposed to include the same boilerplate code. So: is there at least a template somewhere for developers to understand how the whole window state handling/restoration should be done properly?
Apps using Kxmlgui::MainWindow get this automatically. For QML apps which don't use Kxmlgui, we definitely need something standardized, yeah.
https://invent.kde.org/frameworks/kconfig/-/blob/master/src/gui/kwindowconfig.h is a thing which is used by KMainWindow already, either we need a convenient QML type to wrap this or use it directly.
Using it directly from C++ is fine, and some QtWidgets apps like Konsole already do that because they want finer-grained control over the behavior compared to what KMainWindow offers by default. I think it would be nice if we baked it into the Kirigami equivalent of KMainWindow though--which I guess would be Kirigami.ApplicationWindow--or at least made opting in easy via a premade component you can just stick in your top-level application window.