Bug #15329 and window positioning

[Tobias Leupold]

E-Mail von Matthias Klumpp vom Montag, 19. Oktober 2026, 21:00:
> 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.

Thanks a lot for the info!

But long story short: There's no chance that the quite simple code we used
will work again, and we have to hope for experimental code to be merged
into Wayland, along with experimental code being merged into Qt, so that
we can change our existing code to hopefully do what it did before, provided
it's built with a patched Qt version, and executed on a system with a patched
Wayland? And, the worst: All this will only work with systemd stuff (not on
e.g. an OpenRC system)?

That doesn't exactly give much courage :-(

> > 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
>