One of my persistent frustrations with KWin is that I can't get it remember window positions. When I move a window somewhere and then close it, I expect it to be in that same place the next time I open it. But currently none of the offered positioning strategies offer this do what I want, which is basically the following: - If this is the first time that window has been opened, put it in the center of the screen - If the window was previously opened, put it in the same location on the screen where it was when it was last closed - If a second instance of that window is opened, offset it down and to the right, as with the "Cascading" placement strategy (This is requested with Bug 58063) This would match my mental model of how window positioning should work and make window manipulation feel much more comfortable and natural. It's also what other major platforms do these days.
*** Bug 409338 has been marked as a duplicate of this bug. ***
On X11 the problem is that windows position themselves. KWin is almost never involved. You can easily check with xprop. Neither on X11 not on Wayland we have a chance to truly recognize a window. Without protocol extensions it is not possible to implement this - I'm sorry. If it were possible I would have done this years ago.
1. Would it be possible for KWin to override the windows' own placement when using this mode? 2. If the window manager specs don't easily allow for this behavior, can the specs be changed? Particularly for Wayland, which is still accumulating new protocols on a semi-regular basis, I would hope that a spec that doesn't allow for a desirable feature could be changed to facilitate it.
(In reply to Nate Graham from comment #3) > 1. Would it be possible for KWin to override the windows' own placement when > using this mode? Yes of course, otherwise it would be impossible to have tiling window managers. But: there are windows which have to position themselves and with the current protocols we cannot distinguish. If we would override, we would override all, which would break applications like Yakuake, KRunner, every Plasma window, etc. > > 2. If the window manager specs don't easily allow for this behavior, can the > specs be changed? Particularly for Wayland, which is still accumulating new > protocols on a semi-regular basis, I would hope that a spec that doesn't > allow for a desirable feature could be changed to facilitate it. For Wayland I can imagine that a protocol extension gets added. But if you go this route, go back to drawing mode. What we want to achieve is the same positioning of windows. What we don't want is to start with the implementation, what this feature request is. Whether it's a window placement mode or some other mechanism is an implementation detail. If you approach other window managers with the wrong story you will get opposition.
I'm fine with stepping back and assessing the goal before rushing to implementation. :) The goal is to have any window that meets the average user's definition of a window (i.e. it has a titlebar and can be re-positioned and resized at will; basically Windows with an SSD or CSD titlebar) open in the same place on screen that it was located in the last time it was closed.
*** This bug has been marked as a duplicate of bug 15329 ***