Bug #15329 and window positioning

[Tobias Leupold]

E-Mail von Tag Howard vom Montag, 19. Oktober 2026, 21:37:
>  1. That quite simple code is less simple than you think. What if a monitor
>  is unplugged/rearranged? What if the system scale changes? What if the user
>  doesn't *want* you to restore your window state (preferences, window rules,
>  tilers, etc.). There are reasons the protocol exists.
>  2. There is no component that is sytemd-specific, don't know where you got
>  that idea
>  3. xdg_session_management_v1 is supported by kwin and mutter, it is not
>  experimental
>  4. There is no such thing as a patched wayland in this context
>  5. ext-zones is not needed for session restore, only for apps that have
>  multiple windows which need to be positioned relative to each other. And
>  again, enabling it just a plugin, not some patched version of kwin
> There's no big conspiracy to break you apps or kill openrc or whatever.
> We're all just people trying to make kool stuff happen. Sometimes that takes
> time. Sometimes it has rough edges. But at the end of the day I think it
> will be well worth the effort.

Thinking about it, I think the core problem here is also a communication 
problem.

I have no doubt that you all are just people trying to make kool stuff happen. 
After all, I hope I'm also one of those ;-) But what happens is: People like 
me bitch about Wayland, and people like you are pissed like "We put all our 
effort in this, and people keep complaining".

It may be that X11 is ancient, flawed, badly designed etc., Wayland is the 
future and so on. But here, we are at said communication problem. From and 
"end-developer"'s view, using X11, I see my desktop, and I can place my 
program where I want. I store where it was, and I move it there on the next 
start. Using Wayland, I also see my desktop, but placement is broken.

Same for "the simple code is not as simple as one may think": The code to save 
and restore a window position *is* simple. And when somebody uses that, he or 
she doesn't care if the other side under the hood is complex. Same for all the 
Qt stuff we use: I don't care if some class I use is complex under the hood. I 
mean, qstring.cpp has 12,866 lines of code as of now. That is some middle-
sized project on its own – and I simply use it without thinking about this.

I'd also be totally happy if one said "you can't do this this way anymore, if 
you want to also support Wayland, you have to do the following and port your 
stuff". But as of now, there simply seems to be no way to do it.

Of course, such a transition is not easy and has rough edges. Only think about 
the KDE 3 transition to Qt 4 back then (the older folks here may remember it). 
A lot of breakage, a lot of missing functionality – but in the end, it was 
worth it. I hope, the Wayland transition will have the same outcome.

I think the window placement problem is such a central feature and such a 
highly disputed issue that one should improve the communication here. Maybe, 
we could add some wiki page simply explaining what's the problem, how we want 
to solve it, what's the current state and above all why it's worth it. Both 
for end-users and also for devs.

After all, we're the Flagship Linux Desktop, no?!

Again, thanks a lot for working on this!