*** Bug 27969 has been marked as a duplicate of this bug. ***

*** Bug 18578 has been marked as a duplicate of this bug. ***

 See also bug #39946. 
 

> Especially when running at high resolutions it is nice that everything pops up
in the same size on the same place.

Very strongly supported. There should be some way to define strict, unchangeable
by application itself position and size of initial window. All child windows
(optionally) should have the same size. Cascading windows should use the same
initial position incremented by some defineable steps (default values depending
of screen resolution). 

This feature will be valuable specially with business people. Take a look on
business people desktops: most of them want their mail app, text editor, browser
etc. exactly on positions they like, not everywhere decided by some optimization
algorithm. I know :-) I want myself all things on my 1600*1200 desktop to be on
their defined positions, because I am used to that order and do not want to
distract my attention seeking where the hell KMail opened this time and why it
is so small this morning - I need to resize it and bring back to its right place
anyway. Annoying. So to say we need hammer and nails to fix at least main KDE
apps in places they should be forever. Title option Save Settings _doesnt_ do
this, BTW. It too often forgets about place and size.

*** Bug 28224 has been marked as a duplicate of this bug. ***

*** Bug 58771 has been marked as a duplicate of this bug. ***

- I agree : having theire windows alwayse at the same position is needed.
- And have a maximized flag is also good (especialy with the new interactive changing desktop resolution, or orientation... or simply by changing the kicker size).
- It's already doable but few programs, as OpenOffice, overwrite this behavor and I doesn't like : his window isn't maximized and it still few pixels !
- And also, at the moment, we must explicitly specifie which windows will keep theire geometry. But I want save geometrie of ALL windows : please add a mode to ALWAYSE remember windows properties by default.

What KWin III will change ?

*** Bug 79300 has been marked as a duplicate of this bug. ***

*** Bug 81463 has been marked as a duplicate of this bug. ***

Replaced kidcat7@hotmail.com with abrahams@acm.org due to bounces by reporter

*** Bug 85715 has been marked as a duplicate of this bug. ***

*** Bug 97718 has been marked as a duplicate of this bug. ***

NOTE TO SELF: Check all duplicates, especially the last two.

Quoted from Jarne Cook, in description of Bug 97718:

"I see kwin now has the extreme advanced window settings dialog.  In there I can set each app to have it's size/pos remembered.  This is a nice feature but it's is very inconvenient.  To have to right click for every application is just overboard."

Agree. Not only one need to set each app to have it's size/pos remembered but in fact it's necessary for every _window_.  For exampe, I need to set RClick -> Advanced -> Store window settings for EACH WINDOW I use with Mozilla (and there usually are lot's of Mozilla windows on my desktop, and I don't like tabs, thank you). If I have used previously e.g. not more than 6 Mozilla windows and decide to open the seventh one, it will pop up in some hard to predict weird position and I will have to adjust it and set "Store window settings" for it individually. 

Well, this is better than not to have any position/size remembering at all (like it used to be some time ago), but nevertheless "overboard". 

In my humble opinion it would be much better if option "Remember" will refer to whole application and it's windows, by default according window placement policy.  For example, if I have set Placement as "Cascade" and set "Remember" with main application window, then additional windows should come up cascaded (if not set specifically with "Remember"). 

Harry,  
using KDE 3.2.3 coming with Mandrake 10.1 x86-64 Commercial. 

I strongly support this wish!
It drives me nuts to have a "economic" placement, because for ME economic means a window pops up, where I last closed it. This makes it "economic" for me to find the window.
"economic" is great, if you like it. Also, you can use an "economic" placement, if a window is opened for the first time.

"random" position is some odd feature. Who actually uses it?

PLEASE add a policy "remember". And make it remember different functions of konquerer (one placement and size for file browsing, one other for internet browsing...)

*** Bug 121736 has been marked as a duplicate of this bug. ***

Many apps already have the functionality to remember the window state, and some have the ability to remember the window position and size (like kdetv).
Perhaps a general framework for remembering those settings would be useful.

> I want to save the geometry of ALL windows: please add a option to ALWAYS remember windows properties by default. 
ACK!

I use Linux/KDE (2048x768) inside vmWare on a dual-screen host (2560x1024). So X & kdm don´t know about two screens and just realize the wide resolution. So windows open often in the middle of both screens or with 70% of the desktop-width what results in ultra-wide widgets. What would happen with a 4000px wide (virtual) desktop? The windows would spawn overweening wide - so they need to know their 'common size' (something between minimal size to show their content and size of one display) - or at least remember the users demand last time.

The 'smart' windowplacement of KDE 3.5 sometimes opens windows (preferred texteditors) with a size of about 50x50px in a far away corner, if the desktop is cluttered with windows. But two minutes ago I maximized the last application entity vertically and want the current the same.

The functionality of the already available window-specific behavior configuration is great for special demands, so keep it, but it´s not good as missing-default workaround.
(The names of the tabs (at least the german) for this configuration do not really reveal which window-identification is mandatory for a rule. The workflow steps don´t really open up.)

I just wanted to annotate that application-specific transparency-rules also fit this topic, but it´s already there! :)   Thank you, team!!

Beside the option 'remember application size and position when reopen' the smart placement (and sizing) would be much smarter if it could be defined that kde lives inside a dual-, tripple-, n-monitor configuration. 
Depending on this, another 'smart' placement-strategy would work: 
where to place new windows on screen: left screen, center, right screen, top, bottom, or the screen where mousepointer is on.

I have to note, that I haven´t tryed xinerama already.

If the host system is dual-head and the client system inside VMWare doesn't know about this, then I'd consider this to be a VMWare problem. You can use http://ktown.kde.org/~seli/fakexinerama/ to force a specific Xinerama setup.

KDE must remember positions and size for all apps, for better desktop experience.
It's very annoying to have to resize the applications each time they boot.

Yes, it can be done by hand with KWin, but this is something that KWin should know do by himself (like MS Windows, for example).

It is indeed something that should be fixed. Some apps (ex. adept) open in a ridiculously small window. It is very annoying and still there on kde 4.1.85

*** Bug 191375 has been marked as a duplicate of this bug. ***

Jesus, opened 10 years ago, 322 votes, and the bug is still here?!

Please, implement this feature. It is more relevant than ever with KDE4 and the plasma widgets. My notebook has an extra-wide screen, so I prefer to place a few plasmoids on the right hand side of the screen, and I don't want any windows to cover them. Unfortunately the "smart" (more like "dumb as hell") placement puts every window there (since there is already a window in the top left corner). Firefox remembers its position, but the KDE apps don't.
(On a side note, you could also modify how the "smart" placement works -- or just rename it to "corners".)

Remembering the size would also be nice, I hate how Adept always opens in such a small window.

Searching for a solution for making window positions permanent, I found lots of instructions on "window rules". Some months, and some researchers later I find this bug and see it is open from 2000.

 - Is there an official choice/policy on NOT doing a "remember all window positions"? If so, these bugs should be closed as WONTFIS

 - Is there an implementation difficulty? If so, it would be very nice to hear this from developers. 

 - Is the only thing that we lack is manpower and developer interest ? The issue can be proposed in Summer of code, or a call-to-arms can be published on developer blogs to implement this highly wanted feature.

First off: it's Martins decision. I'll just share my personal opinion on this.

There seem three requests here
a) make kwin store all window positions
b) make kwin store all window dimensions
c) make kwin shrink it's placement area

Dealing (c) first - this feature does actually exist. It's called "struts". They can set by *any* client (including the desktop) and usually are by docks. They will also have the in the apparent context "nice" side-effect to constrain the maximization area.
To make that very clear (while I think I have on some plasma-desktop bug):

    IT IS NOT REQUIRED TO HAVE AN ACTUAL DOCK TO ADD A STRUT¹

The solution in the named usecase (which makes me wanna bash "Why do ppl. want to add important stuff to their desktop where it's covered by some windows anyway. What's the whole point of SuperKaramba") would be to have plasma-desktop to optionally add some virtual struts (== dead area from the screen edges) for it's plasmoids.

As a result
1) new windows would not be placed in that area
2) maximizing a window would not make it cover that area
3) moving a window across that are will require a "free" move (alt+lmb or specially featured by the decoration) resize but is still possible

----

Now regarding (a), that is to re/store all window positions: "Client job. Period."

1) 100% exact identification of a window is not possible for the WM as it is for the Clients

2) Braindead implementation approach.
The WM would have to keep a (fast growing) list of all windows to check _everytime_ a window is mapped. Taking every client window you once opened, every dialog and the fact that window properties (including even the classname by every frickin' minor version - ask firefox...) change "under the hood" ie. without any chance for the WM to know that this window will never show up again but is replaced by some other" or that we'd have to invoke the title for precise identification means that we're very soon talking about megabyte dimensions for that list. Meaning you can forget about the CPU cache. (That translates: "dog slow")
On the other hand, the client only needs to store only two numbers and in the beginning tell the WM "please place me here, thank you".

-> task for kdelibs/kmainwindow, but:

3) Very debatable functionality. The exact position is stored alongside and thus across sessions. Makes sense because it means you get the desktop you left.
Placing a window at the exact same position it had last time while the desktop may have completely changed in the meantime (you plasmoid setup, other windows, ...) doesn't sound "smart" at all but more like intrusive (the window might be placed right under the pointer leaving a click at an unintended target; it might cover other windows while there would have been plenty of space where it would not)

---

b) Shares points (1) and (2) with (a) but in general makes a lot of sense, why this is the default behavior of kdelibs/kmainwindow and even per screen size. (That is, when you closed a window @ 1774x1216 while your netbook was attached to your cinema display, it will still open at 1024x600, as it closed last time on the netbook display)

KWin provides the rules as workarounds for legacy or broken or whatever clients which do not provide this functionality, but for Implementing this as a general feature, see (a.2)

===> My personal conclusion:
* Clearly "WONTFIX" -at least not implemented in the WM-for (a)
* WORKSFORME for (b)
* (c) is misassigned. I admit to have no plasmoids on my desktop so i cannot judge on whether this makes sense, but it can and must be done by the client interested in restricting the placement area (plasma-desktop in the apparent case)

[1] Implementation detail:
Ok, kwin does a sanity check whether the requesting client is a dock. It's however ok to have an 1x1 offscreen dummy dock and make it add random struts.

Re. post #25

An interesting take on things (works for me) but doesn't solve the problem. 

Fact is that each app used here at present is not saving it's window size+position in a reproducible way.

Main windows, sub menus, dialogues, are all affected here in v 4.6.5 it's a ridiculous situation in 2012! Having pinhead sized "windows"...pop up for an application start-up.

Most especially perhaps when M$ has got this right from year 1998 at least.
Yeah, a rant, but I'd fix it if I could and not take an arrogant stance (Martin) that helps nobody.

> Main windows, sub menus, dialogues, are all affected here in v 4.6.5 it's a
> ridiculous situation in 2012! Having pinhead sized "windows"...pop up for an
> application start-up.
it might be possible to use the JavaScript bindings for it. Just use a huge 
map with the positions of your windows and listen to Client added. It can fix 
your problem, but is nothing to go into the window manager itself.
> 
> Most especially perhaps when M$ has got this right from year 1998 at least.
There is nothing wrong with using Microsoft Windows if it suits your needs 
better. Unfortunately it doesn't make any sense to point out that Windows 
supports this as that doesn't fix problems. Mircosoft is in the lucky 
situation of controling the complete Windowing System. We rely on what X 
provides.
> Yeah, a rant, but I'd fix it if I could and not take an arrogant stance
> (Martin) that helps nobody.
Calling people arrogant in a bug report makes it very likely that they will 
start implementing your desired features.

Not sure, but since Martin hasn't commented on this at all so far, I must assume that you accuse me of an "arrogant stance"?

Fact #1
Microsoft has actually nothing. There's nothing such as a WM on Windows but applications handle their window management pretty much themselves. For at least the dimensions that means they (those which actually do, what's NO WAY the general case) store them in their registry group and restore them on re-launch...

Fact #2
... what is -as mentioned- pretty much the same as (nearly) all KDE applications do. If they do not for you (you didn't specify what applications pop up "pinhead sized") that is clearly a bug, but likely a local one (sorry) like insufficient access permissions an (ivalid, would be bug - yes) major strutting. You should name those clients and then start to investigate why they do as you observe, for this is NOT the behaviour on any system i've ever been in touch with why the "works for me" statement is not arrogant but simply reality.

Fact #3
I not a single client tries to always restore it's former *position* (what is especially defined by the ICCCM spec and generally honored by kwin, except for explicit rule overrides) that means that either *all* application delevopers, DE engineers and HIG experts are arrogant or stupid - or no one is.
I'll happily read your paper to lay out why this would be a generally resonable behaviour.

Fact #4
I have no idea what you take as "sub menus" but ("popup-")menus
a) are not handled by the window manager at all
b) (dynamically) calculate their dimensions to fit the content
c) are (dynamically) placed (by the application) related towards their parenting items
d) are neither resizable nor movable by users at all.

esp. if (b) should NOT hold for you, that would mean that for some reason every application on your destop thinks that you've an unreasonably tiny workspace (but it would also mean that you couldn't "maximize" them any bigger)

Thanks for the response and I owe you an apology, therefore I apologize.

I had just read something from you in another medium and it was rather blunt but I realize now that English may not be your first language. also I'd just resized a Firefox window for the umpteenth time.

As a strong advocate of Linux, KDE, FSF etc. and an 'assistant' to more than a few senior citizens it really irks when stuff like this "window forgetting" happens. Try as I might I cannot honestly defend a criticism that follows these or similar events. No Microsoft products in use here as they don't suit me. :)

(In reply to comment #28)
> Not sure, but since Martin hasn't commented on this at all so far, I must
> assume that you accuse me of an "arrogant stance"?

Sorry for the misunderstanding, it was a blunt statement made on the subject (attributed to Martin) that upset a few people.

> Fact #1

Thanks
 
> Fact #2
> ... what is -as mentioned- pretty much the same as (nearly) all KDE
> applications do. If they do not for you (you didn't specify what applications
> pop up "pinhead sized") that is clearly a bug, but likely a local one (sorry)
> like insufficient access permissions an (ivalid, would be bug - yes) major
> strutting. You should name those clients and then start to investigate why they
> do as you observe, for this is NOT the behaviour on any system i've ever been
> in touch with why the "works for me" statement is not arrogant but simply
> reality.

Ok thanks, in short almost any GUI type that I've used appears to do this. A clue for me might be that KDE 3.5, 4.5, held the settings and 4.6.5 doesn't.
 
> Fact #3
> I not a single client tries to always restore it's former *position* (what is
> especially defined by the ICCCM spec and generally honored by kwin, except for
> explicit rule overrides) that means that either *all* application delevopers,
> DE engineers and HIG experts are arrogant or stupid - or no one is.
> I'll happily read your paper to lay out why this would be a generally >resonable behaviour.

Fair enough, I don't expect to be writing that paper any time soon.

> Fact #4
> I have no idea what you take as "sub menus" but ("popup-")menus
> a) are not handled by the window manager at all

Not clearly stated by me, sorry, "popping-up" could have been said as 'appearing' and refers to any of the windows listed in the "Advanced> Special Window Settings> Window Extra area.

> b) (dynamically) calculate their dimensions to fit the content
> c) are (dynamically) placed (by the application) related towards their
> parenting items
> d) are neither resizable nor movable by users at all.
> 
> esp. if (b) should NOT hold for you, that would mean that for some reason every
> application on your destop thinks that you've an unreasonably tiny workspace
> (but it would also mean that you couldn't "maximize" them any bigger)

Of course what you say makes good sense and I don't know why the effect is experienced but as far as I can tell permissions are fine and as previously mentioned this behavior was almost totally absent in earlier KDE incarnations. It is certainly very bothersome though in my 4.6.5 version.

Re. Workspace, my idea of clutter might not accord with another person's and I might be content to have windows layer upon layer in a single desktop and switch between them. < (just for illustration, I don't do this)

That's okay for me in that instance but unless I'm missing the point does the allocation strategy say in effect, "sorry but this next window is going to be pinhead sized because we have no space available?"

The odd behavior is there in any case even with a single application on an otherwise sparsely populated screen. Just a single instance of Dolphin for example. Opens perfectly first time around, a re-size operation is done and then when opened again as a single app it's squashed up into 'pos 0,0' and so tiny as to be almost unrecognizable.

> (In reply to comment #28)
>> Not sure, but since Martin hasn't commented on this at all so far, I 
>> must
>> assume that you accuse me of an "arrogant stance"?
>
> Sorry for the misunderstanding, it was a blunt statement made on the 
> subject
> (attributed to Martin) that upset a few people.
Now I am surprised that you attribute statements to developers who have 
not yet commented on the bug. But anyway I would like to know to which 
statement you refer which upset a few people. I am not a native speaker 
so I need to know which statements were bad phrased to not repeat the 
mistakes. Feel free to send the reply privately to keep this bugtracker 
clean.

> Now I am surprised that you attribute statements to developers who have 
> not yet commented on the bug. But anyway I would like to know to which 
> statement you refer which upset a few people. I am not a native speaker 
> so I need to know which statements were bad phrased to not repeat the 
> mistakes. Feel free to send the reply privately to keep this bugtracker 
> clean.

OK I'll send you the information privately.

Thank you for all that you do development-wise, and I will not add any more noise to bugtracker.

I can see that a few other writers have stated the "pos,size" difficulty in a more lucid way and it's clearly a problem that could do with a better answer than the one we currently have.

(In reply to comment #30)
> Sorry for the misunderstanding, it was a blunt statement made on the subject
> (attributed to Martin) that upset a few people.
Ok, I guess you just got why ppl. often write: DO NOT CROSSPOST! ;-)

> Ok thanks, in short almost any GUI type that I've used appears to do this. A
> clue for me might be that KDE 3.5, 4.5, held the settings and 4.6.5 doesn't.
If it covers Dolphin, Kwrite, Firefox, Gimp and LibreOffice there's indeed a general (window- or filesystem) issue because they would all work differently in this regard.

-> Did you add any rules to kwin ("kcmshell4 kwinrules", It's general access to "Special Window Settings" management)
==> (esp. if one of them is a "blind" rule matching all windows) please attach your ~/.kde/share/config/kwinrulesrc (the rules are very powerful and *do* allow you to shoot yourself and break your desktop)
-> Do you use multiple (plasma-desktop) activities? (their introduction broke nearly all "remember" rules - see bug #264981

> That's okay for me in that instance but unless I'm missing the point does the
> allocation strategy say in effect, "sorry but this next window is going to be
> pinhead sized because we have no space available?"

NO!
The WM ensures reasonable bounds (ie. not bigger than the workspace and not smaller than the titlebar requires) but that's it.

If the windows are *all* very small that is either
a) because they set this size
b) because a KWin rule explicitly forces them to this size
c) because the workspace is (virtually) restricted to this size (that's why i asked for maximization behavior)

> The odd behavior is [...] Opens perfectly first time around, a re-size operation is 
> done and then when opened again as a single app it's squashed up into 'pos 0,0'

-> Sounds like conflicting remember rules are set up.
Please attach kwinrulesrc as well as the dolphirc (you can strip the latter one from stuff like last path and whatever private information might be stored there - only the mainwindow sections and everything that starts by width/height is relevant)

Thomas Lübking  wrote:
> https://bugs.kde.org/show_bug.cgi?id=15329
>
> If it covers Dolphin, Kwrite, Firefox, Gimp and LibreOffice there's indeed a
> general (window- or filesystem) issue because they would all work differently
> in this regard.
<snipped>

Thanks indeed for the pointers and info!
I'll make some time to get on to this as soon as I can.

Regards
Mac

I am setting this feature request to WONTFIX as it is not possible to implement such a remember policy with our currently used windowing system. Recognizing a window is a non trivial issue. This might become solvable with Wayland but in general remembering cannot be implemented by a window manager or a windowing system, but has to be requested by the clients.

Given that the feature request has been opened more than 10 years ago I consider it as the most honest thing we can do to finally close the request instead of keeping it open in the hope that someday the technical requirements will be available.

I want to thank everybody who commented on this report in order to make KDE suit his needs better. This is of course highly appreciated. I am sorry that we have to close this request and cannot present an implementation.

*** Bug 192060 has been marked as a duplicate of this bug. ***

*** Bug 380799 has been marked as a duplicate of this bug. ***

*** Bug 384091 has been marked as a duplicate of this bug. ***

*** Bug 409349 has been marked as a duplicate of this bug. ***

*** Bug 409338 has been marked as a duplicate of this bug. ***

Re-opening because a similar bug I filed remained open (Bug 79300).

Based on the list of duplicates and votes, It's clear that this is a very highly desired feature by our users and I think we ought to put some effort into trying to make it happen.

Sorry, but this is not possible to implement for a window manager. We lack information to identify that a window is the same as previous window. Please see Thomas's comments on that. As Thomas states this is clearly a client job and we can only do something in frameworks for KDE applications.

On Wayland we lack the same information and I don't see a possibility to add a spec adding the required functionality as it requires each and every application to change. Even Qt API doesn't provide anything to specify the required functionality.

*** Bug 424162 has been marked as a duplicate of this bug. ***

Talked to the current KWin developers and they indicated that this is quite feasible on Wayland once https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18 lands upstream.

Just to set expectations it's when that lands upstream, and we implement it and every client also implements what is relevant.

(In reply to Nate Graham from comment #44)
> Talked to the current KWin developers and they indicated that this is quite
> feasible on Wayland once
> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18
> lands upstream.

Not everyone can use Wayland. For example i cannot because i have an nvidia gpu. No feature should be exclusive to X11 or Waypand.

I'd also like this on X11, but it seems almost impossible to do, after talking with several KWin developers about it in detail. And NVIDIA GPUs are now supported on Wayland, FWIW.

(In reply to Nate Graham from comment #47)
> I'd also like this on X11, but it seems almost impossible to do, after
> talking with several KWin developers about it in detail. And NVIDIA GPUs are
> now supported on Wayland, FWIW.

Well, Gnome somehow does it, i have been using it for some time and it keeps the position and size of 99% of software i ever ran. Even most games ran through Proton.

(In reply to Nate Graham from comment #47)
> I'd also like this on X11, but it seems almost impossible to do, after
> talking with several KWin developers about it in detail. And NVIDIA GPUs are
> now supported on Wayland, FWIW.

Also KDE can currently remember the posotion of windows by adding a window rule. But it has to be done for every program manually and thats unacceptable. But it proves it is curreltly possible. We should get an option to remember all window positions and sizes and be able to add window rules AS AN EXCEPTION to that.

*** Bug 424257 has been marked as a duplicate of this bug. ***

(In reply to qik00yt from comment #48)
> Well, Gnome somehow does it, i have been using it for some time and it keeps
> the position and size of 99% of software i ever ran. Even most games ran
> through Proton.
The last time I tried GNOME, window positions were not remembered. Maybe they implemented this since then, or maybe they made GTK itself remember window positions, which would provide the illusion that their window manager Mutter is doing it, even though it's not.

Would you be able to investigate a bit to see which approach they took?

(In reply to qik00yt from comment #46)
> Not everyone can use Wayland. For example i cannot because i have an nvidia
> gpu. No feature should be exclusive to X11 or Waypand.
I'm afraid that we don't have enough information on X11.

Meh, I'm still not fully awake. The problem is that we don't have enough information on X11 to identify windows and thus place them at their previous position.

Here we are, 20 years after the reporting of this bug/feature request/wish (which wasn't even the first report), and not that much happened. Monitors bacame 5-10x bigger in pixel count and windows popping up in unexpected places are progressively harder to find, but hey?

I now could at length post one or antother episode from my life that happened during those 20 years, but - to sum it up - time progressed for me, I can't really afford to wait another 20 years to get this sorted out (via kwin, X11 or wayland), so, folks, lets be realistic, let's just close this bug 15329, collectively forget about it - it's not gonna happen, nobody capable of coding really cares about it enough - and just happily move on.

If we're really passionate about it, we could come back in 20 years, take a look at bug 15329 and tell our children or grand-children a nice little episode from our lives about the nightmare of crazily positioned windows in KDE and how we eventually learned to live with it.

I bid you a very warm farewell,
live long and prosper
Wolfi

Please learn to code before attacking those who can. Only then you will understand how hard it is. If I misunderstood your comment, and you are indeed able to code, why not suggest a patch?

Christoph: that's a fallacy; you don't have to be a cook to recognize badly prepared food.

This issue has been open for 20 years; I added myself to the CC list 10 years ago, when I was still using KDE. So even if it is a difficult problem, KDE has had all the time in the world to fix it.

Incidentally, on Linux Mint 18.3 Cinnamon, some apps remember their size, some remember their position as well, while others open in the middle of the screen in a default size. It was probably the same for Gnome back in 2009 before I switched to KDE. It's nowhere near optimal, but it shows that the information is  (was) there.

You might be right in saying that this is not a KWin issue, but should be handled in KDE core or wherever. Rest assured, that's completely fine with us, as long as this feature gets implemented somewhere. People using KDE probably mostly use K* apps anyway (with the exception of browsers and Libre Office, which remember their positions).

This isn't about recognizing the issue, but solving it.

(In reply to David Nemeskey from comment #56)
> Incidentally, on Linux Mint 18.3 Cinnamon, some apps remember their size,
> some remember their position as well, while others open in the middle of the
> screen in a default size. It was probably the same for Gnome back in 2009
> before I switched to KDE. It's nowhere near optimal, but it shows that the
> information is  (was) there.
In fact, what you describe is the *lack* of this feature: if the window manager handled remembering window sizes and positions, then no window would ever fail to remember its size or position. But because the window manager does not, it's up to each app (or each toolkit that apps are built with) to implement the feature on its own, which is why it works for some apps but not others.

We all want this feature, it's about figuring out how to do it. If it was easy, it would have been done ages ago.

(In reply to Nate Graham from comment #58)
> (In reply to David Nemeskey from comment #56)
> > Incidentally, on Linux Mint 18.3 Cinnamon, some apps remember their size,
> > some remember their position as well, while others open in the middle of the
> > screen in a default size. It was probably the same for Gnome back in 2009
> > before I switched to KDE. It's nowhere near optimal, but it shows that the
> > information is  (was) there.
> In fact, what you describe is the *lack* of this feature: if the window
> manager handled remembering window sizes and positions, then no window would
> ever fail to remember its size or position. But because the window manager
> does not, it's up to each app (or each toolkit that apps are built with) to
> implement the feature on its own, which is why it works for some apps but
> not others.
> 
> We all want this feature, it's about figuring out how to do it. If it was
> easy, it would have been done ages ago.


> But because the window manager
> does not

Why ? Is there a reason it cant ?

(In reply to Nate Graham from comment #58)
> (In reply to David Nemeskey from comment #56)
> > Incidentally, on Linux Mint 18.3 Cinnamon, some apps remember their size,
> > some remember their position as well, while others open in the middle of the
> > screen in a default size. It was probably the same for Gnome back in 2009
> > before I switched to KDE. It's nowhere near optimal, but it shows that the
> > information is  (was) there.
> In fact, what you describe is the *lack* of this feature:

I wanted to point out three things in my comment, but apparently managed to mix them up.

1. Yes, what I described is the lack of the feature in the Gnome / Cinnamon ecosystem as a whole. However, at least some applications (and key applications like Terminal, Synaptic, etc.) do it, which makes it a much more acceptable experience than in KDE (speaking from memory here, but the issue is still open, so...)
2. The fact that some applications do it means it is possible, and was possible even with X11.
3. While this issue was opened against KWin, we users don't care where the solution will land. If it can only be done on the toolkit level (which is probably better than forcing each app/developer to implement it separately), so be it.

(In reply to qik00yt from comment #59)
> > But because the window manager
> > does not
> 
> Why ? Is there a reason it cant ?
That's what's being discussed by various developers in the comment thread of this bug report. :) There are a variety of technical challenges to making work on both X11 and Wayland. On X11, the challenges relate to various mismatches between what X11 provides the window manager and what the window manager needs. On Wayland, it're more about needed functionality not having been merged into a protocol yet.

Again, if it were easy, it would already be done. :)

(In reply to David Nemeskey from comment #60)
> 1. Yes, what I described is the lack of the feature in the Gnome / Cinnamon
> ecosystem as a whole. However, at least some applications (and key
> applications like Terminal, Synaptic, etc.) do it, which makes it a much
> more acceptable experience than in KDE (speaking from memory here, but the
> issue is still open, so...)
For sure. Similar,y, some KDE applications already support this individually, such as Discover and Elisa.

> 2. The fact that some applications do it means it is possible, and was
> possible even with X11.
X11 limitations don't come into play when the app itself does it.

> 3. While this issue was opened against KWin, we users don't care where the
> solution will land. If it can only be done on the toolkit level (which is
> probably better than forcing each app/developer to implement it separately),
> so be it.
Indeed, that's exactly what Bug 415150 is tracking: having our app framework provide the feature automatically for all KDE apps, in the absence of the window manager doing it automatically.

Of course time is limited, and here I am responding to comments in a bug report instead of writing code. ;)

(In reply to Nate Graham from comment #62)
> (In reply to David Nemeskey from comment #60)
> > 1. Yes, what I described is the lack of the feature in the Gnome / Cinnamon
> > ecosystem as a whole. However, at least some applications (and key
> > applications like Terminal, Synaptic, etc.) do it, which makes it a much
> > more acceptable experience than in KDE (speaking from memory here, but the
> > issue is still open, so...)
> For sure. Similar,y, some KDE applications already support this
> individually, such as Discover and Elisa.
> 
> > 2. The fact that some applications do it means it is possible, and was
> > possible even with X11.
> X11 limitations don't come into play when the app itself does it.
> 
> > 3. While this issue was opened against KWin, we users don't care where the
> > solution will land. If it can only be done on the toolkit level (which is
> > probably better than forcing each app/developer to implement it separately),
> > so be it.
> Indeed, that's exactly what Bug 415150 is tracking: having our app framework
> provide the feature automatically for all KDE apps, in the absence of the
> window manager doing it automatically.
> 
> Of course time is limited, and here I am responding to comments in a bug
> report instead of writing code. ;)

On my PC even Dolphin, not to mention Discover and Elisa do not remember the last size and placement. But they do on my laptop somehow, despite the configs being IDENTICAL

This is in progress on Wayland! See https://invent.kde.org/plasma/kwayland-server/-/merge_requests/69 and https://invent.kde.org/plasma/kwin/-/merge_requests/178

On X11, I just merged a limited version for only KDE apps' main windows, which is the best we can do there. See bug 415150.

*** Bug 429361 has been marked as a duplicate of this bug. ***

Seems that KDE apps ported to Windows are affected by a corruption of the config file ( a lot of "\" characters on the configuration file) and this is placing the main app window on a strange position (with a strange size)

this is an example of a line: 

from this: 
Height 1080=900

to this:
\\\\.\\DISPLAY1 \\\\.\\DISPLAY2 Height 1080=900

That's not related to this issue and is already tracked with Bug 429943.

*** Bug 433836 has been marked as a duplicate of this bug. ***

*** Bug 435357 has been marked as a duplicate of this bug. ***

*** Bug 435914 has been marked as a duplicate of this bug. ***

*** Bug 438599 has been marked as a duplicate of this bug. ***

I would very much love it when the window placement policy of Plasma got a little less jumpy. But if that is very hard to achieve (also under Wayland) I would like to make a suggestion:
only very recent I discovered that once you close an application in ms windows (10) using the window control "x" while at the same time pressing the Shift-key, it will from then on remember the size and position of that specific window.
I find that quite practical. That could be a temporary solution.

Or, to take my thought in the previous comment (72) a little further: perhaps there could be a preference "remember window size and position" that made kwin automatically save a "window rule" when an app is closed.
And in this "window rule" size and position were to be saved.
That way the user wouldn't have to bother about the shortcut Shift-close.

*** Bug 450806 has been marked as a duplicate of this bug. ***

*** Bug 460498 has been marked as a duplicate of this bug. ***

*** Bug 469987 has been marked as a duplicate of this bug. ***

*** Bug 470318 has been marked as a duplicate of this bug. ***

In https://bugs.kde.org/show_bug.cgi?id=470318#c1 Nate explained that X11 apps are allowed to save and restore their own window positions. So I'm guessing that this bug has been open for almost 23 years because this ceased to be an issue on X11, as every app implemented this on their own.

However, Nate also explains in https://bugs.kde.org/show_bug.cgi?id=470318#c1 that on Wayland, apps are no longer allowed to restore their own window positions. This can be seen easily with Firefox.

MOZ_DISABLE_WAYLAND=1 firefox 
Firefox running via XWayland is able to remember its own window position (though there is some visual jank as the windows position in the default spot, and then move to the remembered position).

But when running firefox natively on Wayland, window positions are not remembered.

Nate's comment in late 2020 was about purported progress in Wayland, but this is still not working in 2023. Now that Wayland will not allow apps to remember their own positions, I hope that renewed focus will be applied to this nearly 23 year old issue. For me, this is a showstopper issue for Wayland adoption, as I have many carefully positioned windows with browsers and IDEs and its a major pain to continually reposition Windows across every restart.

FWIW, as a workaround while this feature remains unimplemented, you should be able to use Window Rules on Wayland to manually force windows to appear where you want them.

(In reply to Nate Graham from comment #82)
> FWIW, as a workaround while this feature remains unimplemented, you should
> be able to use Window Rules on Wayland to manually force windows to appear
> where you want them.

I would be very appreciate if you would show working window rules for Telegram window to always appear in upper right screen corner on Wayland.

*** Bug 471996 has been marked as a duplicate of this bug. ***

*** Bug 472818 has been marked as a duplicate of this bug. ***

Same issue.  Need all apps to assume their last known position on start and when monitors are removed/added.

*** Bug 481193 has been marked as a duplicate of this bug. ***

*** Bug 484305 has been marked as a duplicate of this bug. ***

(In reply to Nate Graham from comment #82)
> FWIW, as a workaround while this feature remains unimplemented, you should
> be able to use Window Rules on Wayland to manually force windows to appear
> where you want them.

Trying to use this workaround but its very difficult to do properly. The "Screen" window rule for example takes a screen index as its value, but screen index doesn't even exist any more in Display Properties which now uses screen priorities and monitor model and serial numbers. Using "Apply Now" or "Force" and changing the index to 0, 1, or 2, does absolutely nothing on my triple-monitor setup, when testing with a Google Chrome window matching on window  window title.

Its so frustrating that this is impossible to do properly on Wayland. Is there another issue I can follow for this missing functionality (and hopefully not for years)?

Operating System: Fedora Linux 40
KDE Plasma Version: 6.1.0
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.1
Kernel Version: 6.9.4-200.fc40.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 24 × 12th Gen Intel® Core™ i9-12900KS
Memory: 124.8 GiB of RAM
Graphics Processor: AMD Radeon RX 6600 XT
Manufacturer: ASUS

*** Bug 489248 has been marked as a duplicate of this bug. ***

(In reply to Raman Gupta from comment #94)
> (In reply to Nate Graham from comment #82)
> > FWIW, as a workaround while this feature remains unimplemented, you should
> > be able to use Window Rules on Wayland to manually force windows to appear
> > where you want them.
> 
> Trying to use this workaround but its very difficult to do properly.

FYI: I created these related issues to track the gaps I found while trying to work around this issue with window rules:

https://bugs.kde.org/show_bug.cgi?id=490049
https://bugs.kde.org/show_bug.cgi?id=490050

This bug is rapidly coming up on its 24th birthday, and with more and more distros ditching X11 and this bug still being a dealbreaker for a lot of people (myself included) It would be nice to know if there was a roadmap or a fix or something in the works for this issue?

I searched the bug database for this problem and saw numerous bug reports.  This one seems to be the most recent.
I see very inconsistent behavior.  Once out of about every 10 reboots and logins, I see the Dolphin file manager windows in the same location with the same size as they were when I logged out (or when I directly shut down). 

However, the other 9 times out of 10, the windows are in some completely strange location, sometimes the same size, sometimes a different size.

For instance:  last night when I shut down I had 2 Dolphin windows open.  During the day I had opened a third window (and resized to much bigger than the first two windows); I had closed it during my session, leaving the first two windows open.  

This morning, upon boot and log in, there were 2 windows open; both were of the size of the third (larger) window from the previous day's session, both in the same position as the third window from the previous day's session.

There were no windows in the positions and of the sizes of the first 2 windows from the previous day's session.  Today is the first time I've seen such behavior.

The behavior seems quite random actually.

(In reply to Nate Graham from comment #82)
> FWIW, as a workaround while this feature remains unimplemented, you should
> be able to use Window Rules on Wayland to manually force windows to appear
> where you want them.

Emphasis on "should". While I can make Firefox open always centered with a certain width and vertically maximized most of the times (about 10% of the times the latter doesn't work), so do its dialogs, i.e. primary password prompt, file save, dev tools, etc. There's no sane way to exclude those windows—at least I found none except preceding the rule with "Do Not Affect" rules matching the title.

Aside from that, initial window placement and sizing are a mess. Having observed it for a while now, I'd guess that there are a handful of different bugs causing it, but I can't isolate a single one. One is probably erroneous calculations for my particular display layout (oO - 1080p 100%, primary 4K 125%). Another one might be taking other windows into account even if they are on a different screen or desktop. Regarding the 10% failure rate to apply the window rule mentioned above, I'd guess it's a race condition. Others seem to be third party issues—e.g. Zoom's menu popups are displaced.

And if I understand the Wayland design correctly (I only scratched the surface), it seems to be an inherent issue with it. Tiling window managers suddenly seem very attractive. I'm currently exploring alternatives for all the little things that come with a complete desktop environment. Maybe I'll follow the hype. 😐

By the way, as a fun experiment, start KRuler and move/resize it over two screens with different scale factors.

I've been beta testing early release versions of JetBrains IntelliJ IDEA IDE on native Wayland. My experience with trying to use Window Rules for my IDEA IDE windows completely failed. Many of the popup windows were responding to the same rules. In discussing this with the developers, they say that IDEA's uses regular windows for many of its popups, because "IDEA's UI is very complex and it was not possible to accomplish everything IDEA popups need with what Wayland's popups offer." Reference:

https://youtrack.jetbrains.com/issue/JBR-3206/Native-Wayland-support#focus=Comments-27-10645536.0-0

Furthermore, the positioning of these windows is often simply wrong, showing up on the top left corner many times, or other weird behavior.

Furthermore, many of IDEA's popups are very different sizes and aspect ratios, depending on the specific content being shown.

In thinking about this "Save and Remember Window Positions" issue, I'm not sure how the window manager is supposed to deal with and understand all this complexity. Only the application has the knowledge necessary to do this. Furthermore, pretty much every application already has the logic necessary to do it because it had to on X11.

Has anyone considered rethinking the overall approach Wayland takes to window positioning? Or proposed a Wayland protocol or something that would allow applications to position their own windows?

On two monitor setup it is pain in the ass to restart the PC, since all windows pop up randomly on a different monitor, each time you have to move the windows to the desired monitor by hands. 

And when there are 8-10 of these windows after startup, it really hurts...

(In reply to Raman Gupta from comment #100)
> Furthermore, the positioning of these windows is often simply wrong, showing
> up on the top left corner many times, or other weird behavior.

That seems like a bug in KWin - it should not create a new window in the top left corner unless there's a really good reason.

> Has anyone considered rethinking the overall approach Wayland takes to
> window positioning? Or proposed a Wayland protocol or something that would
> allow applications to position their own windows?

AFAIK the best (most likely to move forward) work about giving apps more control over new window positioning is `ext-zones` (https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264) that is being discussed and has a KWin prototype implementation. This isn't moving in any sort of speed actually relevant to an actual client implementation, but maybe if IDEA devs can hop in on the discussion and offer an perspective and an actual client implementation (based on the KWin prototype) - maybe it can move things forward.

I might be offtopic now, but. Hard to say, if remembering position and size should be on application itself, or on WM. I would say, application should/must handle it by itself.

I used to be hobby "dev" (10 years ago) on Windows with C# and I had to write my routine to save window size and position. Luckily it was pretty easy, few lines of code using Windows Registry and I saved window dimensions (x, y, width, length attributes) on OnQuit event.

I really wonder, that developers didn't implemented it in own software in Linux world, rather waiting 20 years to fix it by WM. I know nothing about development on Linux, but in most dirty way I would save dimensions in file somewhere in ~/.config and to save HDD/SSD writes, wouldn't save it on OnResize but only on OnQuit event.

Seems that some KDE apps have it implemented somehow, because Dolphin, Konsole remember size and position. For example KMail nothing.

I just tested KeePassXC - nothing saves. Clementine saves window size but not position.

Just tested. Dolphin and Konsole do remember size, but not position, they always open centered (if were not maximized) on a one screen system.

By the way, there's a deeply buried option for window placement:
System Settings -> Window Management -> Window Behavior -> Advanced -> Window Placement

Regardless of that option, some dialogs, e.g. the master password dialogs of KWallet and Thunderbird, are always placed top left. The one of Firefox is centered, though. After a Plasma update, the KWallet dialog moved even further to the left. If the mouse had not yet been moved after login, windows used to open on my primary screen. Now they open on my secondary screen (which is the left-most).

Regarding window rules: as long as applications don't set distinct window classes for different kinds of windows, they won't be really helpful.

I have also tried to create a generic Window Rule trying to achieve that KDE is remembering all windows individually or at least group all windows with the same window title.
Specifically when using Firefox with 20+ open windows it's very annoying when they all open in the same spot overlapping each other. Unfortunately no combination of using ".*" regular expression or defining "Unimportant" for class or type worked as expected.
I would be OK if I have two Firefox windows (same class) and identical tab URL active (same window title) opening in same location and size. But mostly the windows are having a distinct title and I would like to make KDE remember size and position for each window with this title individually. Without having to create a manual rule for each window before closing it.

So KDE would actually have to save the location and size for each unique set of class and title.

While this sounds easy I am rather also thinking about how to clean up this "database" of class/title matches as an ever-growing list of titles stored might cause waste of resources. Thinking about it KDE might just store another set of class/title list when a process is closed and discard all earlier saved values for windows with titles which do not exist any more at time of closing the class. Not sure if that makes sense. At least it's very annoying having to re-arrange all windows of multi-window applications like Firefox on each start.

*** Bug 500958 has been marked as a duplicate of this bug. ***

*** Bug 503446 has been marked as a duplicate of this bug. ***

Also tried using the Window Rules to create a default Remember rule by setting Window class to Unimportant and found out that didn't work. If it did, adding that as the default rule would solve 90% of this issue seemingly trivially.
I then made per application rules for to remember Size and Position, but a multiwindow Blender runs into another bug. I tried making multiple rules matching the different window titles, but found out that is very inconsistent, Force is the only option that actually affects the secondary Blender windows, or any window using title matching. I'm guessing because the window doesnt have its title set before the rules are checked? The third Blender window gets placed matched same as the second one for some reason, then after moving it for a while some unknown trigger causes it to be rematched and the correct rule's Force options take effect.

Moving from Windows and Mint Cinnamon, this is a pretty big friction point and the first I haven't yet been able to work around. Plasma Wayland is still the most usuable for a multimonitor setup. Please, I'd love for it to be fully usuable.

Operating System: Fedora Linux 42
KDE Plasma Version: 6.3.5
KDE Frameworks Version: 6.14.0
Qt Version: 6.9.0
Kernel Version: 6.14.8-300.fc42.x86_64 (64-bit)
Graphics Platform: Wayland

*** Bug 479391 has been marked as a duplicate of this bug. ***

I just did a system update, including Plasma, restarted, and saw that my Konsole window positions were remembered. Not perfect, but so much better than what was happening all these years, where all the Konsole windows were usually jammed onto one screen, one virtual desktop. This time, it remembered which windows were on which desktop, and had them in more or less the correct relative positions. Absolute positions: not really, but that's because KDE doesn't seem to remember the layout of my multimonitor setup. I don't mind dragging a few windows a bit, though. Having them go back to the same virtual desktop was the main problem, and that seems to be solved now. Hopefully this is not just a coincidence.

Plasma 6.3.5
Qt 6.8.3
Kernel 6.12.21 (Gentoo)
X11

Plasma 6.3.x does not have this fix. 6.4 will have.

But as I tried  on on Fedora 42 (via https://copr.fedorainfracloud.org/coprs/g/kdesig/kde-beta/) I can tell, that KDE Gear 24.04.01 apps do not remember it's positions/sizes.

Seems we have to wait Gear apps also supports it. By now Kcalc window always pops up on the center of the screen.

Plasma 6.4 released, I installed it:

This function is still not back, nor to be found in the settings where it used to be when it worked, nor anywhere else.  I miss it a lot.

I have close to zero tolerance for people who misuse Bugzilla. This is not a discussion forum.

(In reply to Graham Perrin from comment #120)

Indeed. For those who want to state their dislike of the current state of affairs, I implore that you explain your stances at https://discuss.kde.org/, rather than here. There's no intent to silence anyone here, just a lot of people who don't want to be notified of every message posted.

I know this is probably not the right place to ask and I'm fine if a moderator hides this as spam or off-topic, but I'd appreciate if someone can point me in the right direction or tell me if this is even possible.

I’m porting a JPEGView feature (Windows image viewer) to qimgv: when you zoom in/out, the app window resizes to match the image size, there's a little more into it, but that's the general idea.

On X11 everything works perfectly but on Wayland, I can resize the window, but it always grows/shrinks from the top-left corner rather than from the center. I haven’t found a way to recenter the window or make it expand from its center.

I found this line in Nate Graham’s canned responses about Wayland:
> Native Wayland windows are not allowed to determine where to place themselves on screen at all; the compositor does this.

My questions are:
Is there truly no way for a client to move a window or control the “resize origin” (e.g., expand from center)?
If not, would this require a feature request in KWin, or a new Wayland protocol or portal?

Thanks for any guidance.

(In reply to Sdar from comment #122)

> I know this is probably not the right place to ask and I'm fine if a
> moderator hides this as spam or off-topic, but I'd appreciate if someone can
> point me in the right direction or tell me if this is even possible.

A post in https://discuss.kde.org/c/help/6 would likely be better. You can always tag him and/or reference the relevant BZ comment.

*** Bug 503790 has been marked as a duplicate of this bug. ***

*** Bug 510393 has been marked as a duplicate of this bug. ***

*** Bug 510566 has been marked as a duplicate of this bug. ***

Dug into this a bit, and the current status is that pieces are starting to fall into place:

1. Qt support for the experimental window positioning-based Wayland session restore is in Qt 6.11
2. KWin support for it is in 6.4, but currently gated behind two environment variables you need to set:

QT_WAYLAND_ENABLE_XX_SESSION_MANAGER=1
KWIN_WAYLAND_SUPPORT_XX_SESSION_MANAGER=1

Once Plasma can depend on Qt 6.11, turning it on by default in KWin becomes an option.

In addition, more pieces need to be implemented:
1. Apps need to be launched with their session IDs, so KWin can track them
2. Apps need to add some metadata to identify their windows so KWin can use the Wayland session restore protocol to track them across launches and know what size and position they had when closed.

#1 will require work in Plasma, KRunner, etc.

#2 will require work in all apps Why? Because there's actually no way for a window manager to persistently identify individual windows across app launches without some hints from the apps. Yes, really. It may sound unbelievable, but it's true. So apps need to give the window manager the proper hints. And that's what #2 entails.

For KDE apps, this will be relatively easy, as they already use "state saver" code that just needs to be adapted to set the right hints for Wayland session restore purposes.

For non-KDE apps, it's gonna be the wild west. Expect many to most apps to lag in adoption of this for years and years. So I'm afraid the dream of "remember all window positions automatically without apps having to do anything" is dead, sorry. I'm renaming this ticket to reflect what's feasible.

*** Bug 496674 has been marked as a duplicate of this bug. ***

*** Bug 482816 has been marked as a duplicate of this bug. ***

*** Bug 484318 has been marked as a duplicate of this bug. ***

*** Bug 496063 has been marked as a duplicate of this bug. ***

*** Bug 499842 has been marked as a duplicate of this bug. ***

*** Bug 428864 has been marked as a duplicate of this bug. ***

(In reply to Nate Graham from comment #127)

> For non-KDE apps, it's gonna be the wild west. Expect many to most apps to
> lag in adoption of this for years and years. So I'm afraid the dream of
> "remember all window positions automatically without apps having to do
> anything" is dead, sorry. I'm renaming this ticket to reflect what's
> feasible.

Is this true for all other modern WMs, compositors, and display servers (KWin versus DWM.exe, Quartz, and XOrg 11)? I solely ask in order to know whether this is a deficiency in the Wayland standard (and/or the current X implementation[s]), or whether it's fundamentally infeasible; at least, outside of a very, very monolithic OS.

I see that the original issue states that this is available via alternative WMs, which causes me to believe that an X implementation might have provided this. However, I see little evidence of this, and even Windows 11 solely permits “Restartable applications” to be restarted in this manner.

It's fundamentally infeasible for the window manager to track windows across openings/closings without some metadata to help it. Apps will need to do their part to provide this information.

All of the existing approaches for doing this automatically rely on unreliable heuristics such as the window title, which isn't guaranteed to be the same when a window is opened again.

(In reply to Nate Graham from comment #127)
> Dug into this a bit, and the current status is that pieces are starting to
> fall into place:
> 
> 1. Qt support for the experimental window positioning-based Wayland session
> restore is in Qt 6.11
> 2. KWin support for it is in 6.4, but currently gated behind two environment
> variables you need to set:
> 
> QT_WAYLAND_ENABLE_XX_SESSION_MANAGER=1
> KWIN_WAYLAND_SUPPORT_XX_SESSION_MANAGER=1
> 
> Once Plasma can depend on Qt 6.11, turning it on by default in KWin becomes
> an option.
> 
> In addition, more pieces need to be implemented:
> 1. Apps need to be launched with their session IDs, so KWin can track them
> 2. Apps need to add some metadata to identify their windows so KWin can use
> the Wayland session restore protocol to track them across launches and know
> what size and position they had when closed.
> 
> #1 will require work in Plasma, KRunner, etc.
> 
> #2 will require work in all apps Why? Because there's actually no way for a
> window manager to persistently identify individual windows across app
> launches without some hints from the apps. Yes, really. It may sound
> unbelievable, but it's true. So apps need to give the window manager the
> proper hints. And that's what #2 entails.
> 
> For KDE apps, this will be relatively easy, as they already use "state
> saver" code that just needs to be adapted to set the right hints for Wayland
> session restore purposes.
> 
> For non-KDE apps, it's gonna be the wild west. Expect many to most apps to
> lag in adoption of this for years and years. So I'm afraid the dream of
> "remember all window positions automatically without apps having to do
> anything" is dead, sorry. I'm renaming this ticket to reflect what's
> feasible.

This is the most straightforward, informative answer I have ever gotten regarding this issue on any platform. Thank you for laying it out plainly for a user like me.

(In reply to Simon from comment #136)
> (In reply to Nate Graham from comment #127)
> > Dug into this a bit, and the current status is that pieces are starting to
> > fall into place:
> > 
> > 1. Qt support for the experimental window positioning-based Wayland session
> > restore is in Qt 6.11
> > 2. KWin support for it is in 6.4, but currently gated behind two environment
> > variables you need to set:
> > 
> > QT_WAYLAND_ENABLE_XX_SESSION_MANAGER=1
> > KWIN_WAYLAND_SUPPORT_XX_SESSION_MANAGER=1
> > 
> > Once Plasma can depend on Qt 6.11, turning it on by default in KWin becomes
> > an option.
> > 
> > In addition, more pieces need to be implemented:
> > 1. Apps need to be launched with their session IDs, so KWin can track them
> > 2. Apps need to add some metadata to identify their windows so KWin can use
> > the Wayland session restore protocol to track them across launches and know
> > what size and position they had when closed.
> > 
> > #1 will require work in Plasma, KRunner, etc.
> > 
> > #2 will require work in all apps Why? Because there's actually no way for a
> > window manager to persistently identify individual windows across app
> > launches without some hints from the apps. Yes, really. It may sound
> > unbelievable, but it's true. So apps need to give the window manager the
> > proper hints. And that's what #2 entails.
> > 
> > For KDE apps, this will be relatively easy, as they already use "state
> > saver" code that just needs to be adapted to set the right hints for Wayland
> > session restore purposes.
> > 
> > For non-KDE apps, it's gonna be the wild west. Expect many to most apps to
> > lag in adoption of this for years and years. So I'm afraid the dream of
> > "remember all window positions automatically without apps having to do
> > anything" is dead, sorry. I'm renaming this ticket to reflect what's
> > feasible.
> 
> This is the most straightforward, informative answer I have ever gotten
> regarding this issue on any platform. Thank you for laying it out plainly
> for a user like me.

Yes, many thanks for explaining it all!

I hope you don't mind but did you take a look at this https://store.kde.org/p/2324743 ?
Seems very clever to me...

(In reply to PK from comment #139)
> I hope you don't mind but did you take a look at this
> https://store.kde.org/p/2324743 ?
> Seems very clever to me...

I'm not too familiar with QML but that to me seems to be doing string matching on window titles to calculate a "confidence" [1].  Using window titles has been discussed extensively in these comments already.

[1] https://github.com/rxappdev/RememberWindowPositions/blob/5f7d285092ec94be48a0baf851e3f79d3b954e82/src/contents/ui/main.qml#L167-L190

(In reply to Achilleas Koutsou from comment #140)
> (In reply to PK from comment #139)
> > I hope you don't mind but did you take a look at this
> > https://store.kde.org/p/2324743 ?
> > Seems very clever to me...
> 
> I'm not too familiar with QML but that to me seems to be doing string
> matching on window titles to calculate a "confidence" [1].  Using window
> titles has been discussed extensively in these comments already.
> 
> [1]
> https://github.com/rxappdev/RememberWindowPositions/blob/
> 5f7d285092ec94be48a0baf851e3f79d3b954e82/src/contents/ui/main.qml#L167-L190

Worked perfectly to me.
Thank you.

(In reply to Achilleas Koutsou from comment #140)
> (In reply to PK from comment #139)
> > I hope you don't mind but did you take a look at this
> > https://store.kde.org/p/2324743 ?
> > Seems very clever to me...
> 
> I'm not too familiar with QML but that to me seems to be doing string
> matching on window titles to calculate a "confidence" [1].  Using window
> titles has been discussed extensively in these comments already.
> 
> [1]
> https://github.com/rxappdev/RememberWindowPositions/blob/
> 5f7d285092ec94be48a0baf851e3f79d3b954e82/src/contents/ui/main.qml#L167-L190

I've been using it for a while and can attest that it mostly works but it's not perfect. For example, with Chromium it usually misplaces its windows.

(In reply to Pedro Almeida from comment #142)

> I've been using it for a while and can attest that it mostly works but it's
> not perfect. For example, with Chromium it usually misplaces its windows.

It at least provides, basically, parity with XOrg 11. It wasn't doing much differently, from what I know. Advantages and disadvantages together.

Please avoid turning this bug report into a general complaint about Wayland. The transition has indeed been long and messy for all desktop environments, but we're finally nearing the end of it. Venting here won’t accelerate the remaining work, and may actually alienate the developers who are actively improving KDE’s Wayland support.

This report concerns a specific feature that is already in progress. The protocol has been defined, and integration work is underway in multiple GUI toolkits. The best way to help is to test the current implementations, report any issues to the appropriate projects, and link those reports here so they can be tracked.

This is a bug tracker, not a forum! Please move this discussion to https://discuss.kde.org or elsewhere more appropriate.

Hi, I tried to get window restoring position to work in every way possible.

I added

KWIN_WAYLAND_SUPPORT_XX_SESSION_MANAGER=1

then also

QT_WAYLAND_ENABLE_XX_SESSION_MANAGER=1

I set the Chromium flag, but nothing happened.

I also tried the kwin test https://invent.kde.org/plasma/kwin/-/blob/master/tests/xdgsessiontest.cpp

but even that does not remember the window position.

What am I doing wrong?

(In reply to Guido from comment #149)
> Hi, I tried to get window restoring position to work in every way possible.
> 
> I added
> 
> KWIN_WAYLAND_SUPPORT_XX_SESSION_MANAGER=1
> 
> then also
> 
> QT_WAYLAND_ENABLE_XX_SESSION_MANAGER=1
> 
> I set the Chromium flag, but nothing happened.
> 
> I also tried the kwin test
> https://invent.kde.org/plasma/kwin/-/blob/master/tests/xdgsessiontest.cpp
> 
> but even that does not remember the window position.
> 
> What am I doing wrong?

I don't think you're doing anything wrong.  I just upgraded to Fedora 43... the "Save Session" button has mysteriously reappeared on the Application Launcher, but it still doesn't work....

(In reply to Guido from comment #149)
> Hi, I tried to get window restoring position to work in every way possible.
> [...]
> What am I doing wrong?
Nothing; the feature is simply not implemented yet and apps haven't opted into using it. That's why this bugzilla ticket is in the CONFIRMED state rather than RESOLVED, VERIFIED, or CLOSED.

(In reply to Nate Graham from comment #151)
> (In reply to Guido from comment #149)
> > Hi, I tried to get window restoring position to work in every way possible.
> > [...]
> > What am I doing wrong?
> Nothing; the feature is simply not implemented yet and apps haven't opted
> into using it. That's why this bugzilla ticket is in the CONFIRMED state
> rather than RESOLVED, VERIFIED, or CLOSED.

Okay, but then what is KWIN_WAYLAND_SUPPORT_XX_SESSION_MANAGER for? It should work at least for Chromium and for the Kwin test that implement the protocol.
What is the missing piece?

(In reply to Guido from comment #152)
> (In reply to Nate Graham from comment #151)
> > (In reply to Guido from comment #149)
> > > Hi, I tried to get window restoring position to work in every way possible.
> > > [...]
> > > What am I doing wrong?
> > Nothing; the feature is simply not implemented yet and apps haven't opted
> > into using it. That's why this bugzilla ticket is in the CONFIRMED state
> > rather than RESOLVED, VERIFIED, or CLOSED.
> 
> Okay, but then what is KWIN_WAYLAND_SUPPORT_XX_SESSION_MANAGER for? It
> should work at least for Chromium and for the Kwin test that implement the
> protocol.
> What is the missing piece?

It turns on the experimental functionality in KWin, but that functionality is still experimental and incomplete. Once it's complete, apps still have to opt in as well for it to have any effect, and they haven't.

You'll know when this issue is resolved or at least ready for testing because there will be announcements of it, both here and elsewhere.

Until then, sit tight. We're working on it.

This is a bug report, not a forum thread. Please avoid random complaining that doesn't help anyone work on or resolve the issue itself. Thanks!

*** Bug 516471 has been marked as a duplicate of this bug. ***

*** Bug 520506 has been marked as a duplicate of this bug. ***

Hi people. 

I would like to help finish the implementation of Wayland session restore functionality. 

 I’m trying to understand what remains to reach complete Wayland session restore for windows on multiple virtual desktops in Plasma/KWin.

  Could someone clarify the current implementation split and remaining blockers?

  1. What is already implemented today in KWin for Wayland session restore?
  - Is virtual desktop membership already persisted in restore data?
  - Is virtual desktop assignment already reapplied during restore, or is that still missing?

  2. What is still missing on the Plasma side?
  - Are restored applications already launched with the required session IDs everywhere, or is that still incomplete in plasma-workspace / KRunner / related  launch paths?

  3. For full multi-window restore, what exact app-side information is required?
  - Does KWin need stable per-window identity from apps?
  - If so, what is the expected form of that identity for restored toplevels?

  4. What is the intended restore policy?
  - Should virtual desktop assignment be restored before first map?
  - What is the fallback if the saved virtual desktop no longer exists?
  - Should fresh launches ever reuse prior placement, or only true session-restored launches?

  5. What is the current blocker for the browser case specifically?
  - If Firefox/Chromium/Brave restore multiple windows, is the main limitation currently KWin, Plasma launcher/session-ID plumbing, or lack of app-provided
  per-window identity?

  6. What is the preferred current test path?
  - Which Plasma/KWin version, branch, or merge requests should people test?
  - Which environment variables or feature flags are currently required?
  - Is there a known “partially working” scope already, such as single-window or single-desktop cases?

  7. What would KDE consider feature-complete for this work?
  - Single restored window on the correct virtual desktop?
  - Multiple restored windows each returning to their prior desktops?
  - Native Wayland only, or XWayland too?

Any and all direction or advice on how to proceed will be graciously accepted. 

  My test case is:
  - Fedora 44
  - Plasma on Wayland
  - NVIDIA GPU
  - Firefox and Brave
  - On X11, restored browser windows return to the correct virtual desktops
  - On Wayland, after a new Plasma session, they reopen on one virtual desktop instead

I just realized that Plasma 6.6.7 is going to allow per display virutal desktops.  

  1. How will per-display virtual desktops be represented internally?
     Does KWin treat them as:
      - one global desktop model plus per-output active desktop selection, or
      - separate desktop sets per output?

  2. What exactly must be persisted for restore?
     Is the saved state now:
      - window -> output + desktop
      - or window -> workspace topology object of some kind?

  3. What output identity is considered stable enough for restore?
     Should restore use:
      - connector name like DP-1
      - EDID-based monitor identity
      - a KWin internal output UUID
      - something else

  4. If the original monitor is missing, what is the fallback policy?
     For example:
      - same desktop number on the primary monitor
      - current monitor and current desktop
      - nearest surviving output
      - same logical position if possible

  5. If the monitor layout changes, which state has priority?
     If KWin cannot satisfy both:
      - original output
      - original per-output desktop
      - original geometry

     which one should win?

  6. Are per-display desktops globally named or output-local?
     If a window was on “desktop 3” on monitor B, is that desktop identity meaningful without monitor B?

  7. Can restored windows move across outputs during fallback?
     If so, under what rules?

  8. What happens if the number of per-display desktops changes between sessions?
     For example, a window was on desktop 5 of monitor 2, but that monitor now only has 4 desktops.

  9. How do activities interact with per-display desktop restore?
     If activities remain part of the model, restore semantics could become:
      - activity
      - output
      - per-output desktop

  10. What is the intended behavior for multi-monitor browser sessions?
     If Firefox or Brave had multiple windows spread across outputs and desktops, what app-side identity does KWin need to restore them correctly?

  11. Will the current session-restore protocol need any KDE-specific extension for per-display desktop restore?
     Or is this entirely compositor-side policy once KWin has stable window identity?

  12. What should testers validate once per-display desktops land?
     Ask for a concrete matrix such as:

  - one window, two monitors
  - multiple windows across outputs
  - dock/undock between sessions
  - missing monitor on restore
  - renamed/reordered outputs
  - mixed XWayland/native Wayland apps

Thanks

*Plasma 6.7, not 6.6.7

*** Bug 482816 has been marked as a duplicate of this bug. ***

 I have upgraded to 6.7.0 and tried using Wayland. I logged in and rearranged all my windows how I like them across the 4 desktops that I have. I logged out. On logging back in again all my windows where on desktop 1 and centred (if not full screen). For konsole it didn't remember I had 5 open,it  just opened 1 dead centre on desktop 1. Kate, dolphin, kontact, brave, firefox and slack all opened on desktop 1. This is really frustrating, particularly as the plan is to remove X11 in 6.8. A window manager should be able to remember and position the windows it is responsible for. This should not be the responsibility of the individual apps. They should be able to tell the window manager if they want to override the current settings (e.g. like happens for maximise, minimise, move) but by default the window manager should handle their size and positioning and remember them for the next session by default. So I have reverted back to X11. Thanks.

As a script stopgap, this works in 6.7: https://github.com/rxappdev/RememberWindowPositions. 

It's certainly improved since early versions, but it's not perfect: with Slack set to Autostart on login, open and tile 8 threads across multiple screens positioned by topic, log out and back in, and enjoy the centered cascading fun if Slack app beats the script to init by a few ms.

Race conditions like that likely wouldn't be a problem with a native implementation, but good luck getting every app developer on board, particularly opaque corps. 

Full disclosure that I'm still using X11 for VNC reasons, but that script would make Wayland usable in most of my multi-window positioning cases. We're close but no cigar yet.

This is a bug tracker and not a forum. Here are 165 people on the CC list for receiving updates on the bug, which is still marked confirmed and not "fixed". Please move this discussion to discuss.kde.org or somewhere else more appropriate. Thanks!

Could you please move the X11 advocacy off Bugzilla, and especially off this bug?

The KDE developers are already working to improve Wayland session restore; there's absolutely not need to put pressure on them here, and it might actually create a hostile environment for those who want to contribute constructively.

Folks, you are spamming 165 people with off-topic comments, which only make it more frustrating for the people who do want to work on this. Please move all opinionated, non-technical discussion to the forums.

*** Bug 522000 has been marked as a duplicate of this bug. ***

This has gotten out of hand.
The last round of comments are almost all violating the Code of Conduct. Cease being rude, or accounts are going to start to be banned.

https://kde.org/code-of-conduct/

I’ve noticed that work has already begun on removing X11 from Plasma 6.8. However, this bug, which was a blocking bug, is still open. Is there any hope that it will be fixed before the release of Plasma 6.8? The work to remove the legacy code should be done after this bug has been fixed, not before.

(In reply to WoodPek from comment #201)
> I’ve noticed that work has already begun on removing X11 from Plasma 6.8.
> However, this bug, which was a blocking bug, is still open. Is there any
> hope that it will be fixed before the release of Plasma 6.8? The work to
> remove the legacy code should be done after this bug has been fixed, not
> before.

This bug is likely easier to work with when there aren't two competing backends.