https://bugs.kde.org/show_bug.cgi?id=470318
Nate Graham <n...@kde.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REPORTED |RESOLVED
Resolution|--- |DUPLICATE
CC| |n...@kde.org
--- Comment #1 from Nate Graham <n...@kde.org> ---
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.
If you'd like more details, read on. The way window placement works is as
follows:
On X11
======
Per the X11 spec, windows are 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 their own windows whatever they want, 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 X11 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, if 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.
*** This bug has been marked as a duplicate of bug 15329 ***
--
You are receiving this mail because:
You are watching all bug changes.
