SUMMARY Flatpak windows open with a default size instead of the last used size like "regular" windows. STEPS TO REPRODUCE 1. Run a Flatpak app 2. Resize/maximize/move the window 3. Close the app 4. Open the app again OBSERVED RESULT The app opens with some default size at the center of the screen. EXPECTED RESULT It opens with the last size and position like native windows would. SOFTWARE/OS VERSIONS KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.106.0 Qt Version: 5.15.9 ADDITIONAL INFORMATION Tested on X11.
So this particular app window has size and position saving working correctly on X11 when not run in a Flatpak? What window/app is it?
Looks like I was wrong. I thought that this is handled by KWin/the framework and not the app itself. In the tests below, Flatpak and native behave the same: with "Placement=Maximizing" - Elisa opens with the last size/position (not maximized) - Audiotube opens maximized without "Placement=Maximizing" - Elisa opens with the last size/position - Audiotube opens centered with a default size To be honest, I'm a bit confused about who is responsible to handle this: The KWin placement setting indicates that it's KWin but if even two Kirigami apps behave differently... Without knowing the internals, my expectation from a user perspective would be that KWin can force any window (including GTK etc) to follow the system configuration. Does this mean that every app must store its last position/size individually? If so, what's the reason for this? Why doesn't KWin handle this?
So the way window placement works is as follows: On X11 ====== Per the X11 spec, windows are is allowed to place themselves on the screen--but they aren't required to. If a window doesn't, then KWin places it according to its placement policy, which is user-controllable. This includes XWayland apps run in a Wayland session. KWin *could* in theory ignore this and forcibly place X11 windows according to its placement policy. But doing so unconditionally would not only break the spec, but in practice it would also break apps that were developed with the expectation of being able to place themselves, so instead this is an opt-in thing that you as the user have to turn on via the Window Rules system. Because that would be annoying, many apps implement their own "remember my window positions" feature. And many--but not all--KDE apps do so on X11. In QtWidgets apps that use KDE's KXMLGui framework for the main window, it's a standard feature that apps' main windows get automatically, and whether or not to do it is controlled by the "Allow apps to remember the positions of their own windows, of they support it" checkbox that's on the "Advanced" page of the Window Behavior KCM. For Kirigami-using apps, there is no central automatic thing for it as with KXMLGui because Kirigami is a tier 1 framework and therefore cannot depend on KConfig, and it would need to do so to be able to write the necessary data into the app's config file. As a result, Kirigami-based apps often implement this logic themselves in a custom way. A way to improve the status quo would be to write a standard "WindowStateSaver" object (or whatever) that lived in like Kirigami-addons or something and contained the window state saving logic in a central place, and then Kirigami apps that want to use it could opt into it by importing kirigami-addons and adding that object to their windows as needed. So yes, as you can see, this is a mess. :) On Wayland it's much simpler: On Wayland ========== Native wayland windows are not allowed to determine where to place themselves on screen at all, and as a result, app windows always respect KWin's placement policy. So KWin itself would have to gain a "remember window positions" feature, but then once it did, it would apply to all native Wayland windows. This is tracked in Bug 15329. > Without knowing the internals, my expectation from a user perspective would be that KWin can force any > window (including GTK etc) to follow the system configuration. Agreed, and this was in fact one of the first bug reports I submitted as a user. The TL;DR version is that this will become a reality once all windows are native Wayland windows and Bug 15329 is implemented in KWin.
Ok, understood. Thanks for the explanation.