Bug #15329 and window positioning

[Matthias Klumpp]

Hi!

Am Mo., 19. Okt. 2026 um 20:02 Uhr schrieb Tobias Leupold <tl at stonemx.de>:
> [...]
> We're dropping X11 and apprently also alternative approaches like XLibre in
> favor of Wayland. If or if not this is the right thing to do is another
> question. However, this hit me today when I upgraded my Artix notebook. The
> most visible change was that window positions were not restored anymore. I got
> back the size, but not the position.

Wayland unquestionably is the future, I do expect there to be a time
when maintaining both X11 applications as well as compositors will not
be feasible anymore (it's highly complex code and even today mostly
works with workarounds).

> On my Gentoo box, I'm still a happy X11 user, and I never cared about Wayland.
> Everything works. Wayland? Positioning broken. So I thought: "WTF?!". Now I
> found that we have tons of bug reports concerning this exact problem. Most of
> them marked as a duplicate of Bug #15329. This bug has been filed in 2000. It
> will be 26 (yes, twenty-six) years old in November.
> [...]

This has been a hot topic for a while. I worked on addressing it with
three different proposals, xx-zones is where it has currently settled
at. If you have a lot of time, you can have a look at:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264
(as well as the prior two MRs that this one is the successor to).

The reason why this is not implemented in KWin and why many Wayland
compositor developers are hesitant about it, is that they worry that
such a feature will be abused by applications to do nonsensical
things, like using a borderless toplevel window as a popup or menu
instead of going through the proper Wayland protocols.

> For almost two decades, my approach for Qt programs was to call restoreState()
> and restoreGeometry() with previously stored saveState() and saveGeometry()
> values. With KXmlGuiWindow, this even got a bit smarter later. This broke
> after being forced to use Wayland now. Will I get it back? Or what's the plan?

So, xx-zones is primarily for applications to give window position
hints to new windows, but it can be used to restore positions the
traditional way as well.
Currently on KDE, we have the kwin-zones plugin that adds support for
the protocol:
https://invent.kde.org/automotive/kwin-zones

It can be paired with libwinpos in Qt applications to achieve what we
have today on X11/Windows/macOS: https://github.com/ximion/libwinpos

If it is just about restoring window positions of closed applications,
and not also setting initial positions, then another solution that
might address your issue is the xdg-session-management protocol, a
protocol that KWin *does* implement:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18

The issue with that protocol is that its mechanism is entirely
Wayland-unique, so the existing Qt APIs also won't work with it. But
support for it will come in time, at least for KDE applications.
Another solution for you *right now* would be to set up custom window
rules in KWin to position windows where you want them.

> Getting legitimate information about this seems to be quite hard with all the
> rants and flamewars. So thanks a lot for all insights!

Hopefully this is helpful, as an overview of the scene! The
session-management protocol should be more widely available soon(tm),
window rules exist now already. For the xx-zones protocol, the
kwin-zones plugin is quite widely available in Linux distributions for
testing purposes, and the protocol also has a few toolkit
implementations. From experience gained with the experimental
protocol, I intend to make a new attempt to move it out of
experimental eventually, but there are some potential simplifications
that can be made to it if the (also pending) window grouping protocol
gets merged first. To help with the concerns of compositor developers,
it is also possible that the protocol will gain a "window must
advertise window decoration" prerequisite for positioning (bad news
for splash screens) or that the protocol would be permission-gated.
The latter will be possible once we have systemd-appd, so the
compositor can selectively enable the protocol for applications that
have positioning permissions.

So, this issue is definitely not solved yet, but it's also not
abandoned (there are professional apps that need it, and "restore
state upon relaunch" is definitely something that people have thought
about for a while).

Best,
    Matthias