Placement policy 'Remember' by default for all windows

[usr]

Binary package hint: kubuntu-default-settings

The desktop evironment 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.

This bug affects to Ubuntu, Kubuntu, and Xubuntu.

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

[Kidcat7 (kidcat7)]

(*** This bug was imported into bugs.kde.org ***)

Package: kwin
Version: 2.0
Severity: wishlist
Installed from: Mandrake 7.2 RPM

I think that the placement policy should have en aditional feature called 'Remember'. M$-winslows has this feature and it is awfully nice... Especially when running at high resolutions it is nice that everything pops up in the same size on the same place. I know that other WM's has this feature so it should not be hard to implement ;)

(submitted via bugs.kde.org)

[L-lunak-5 (l-lunak-5)]

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

[L-lunak-5 (l-lunak-5)]

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

[L-lunak-5 (l-lunak-5)]

 See also bug #39946.

[hbush (harijs)]

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

[L-lunak-5 (l-lunak-5)]

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

[L-lunak-5 (l-lunak-5)]

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

[Sébastien Laoût (slaout)]

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

[L-lunak-5 (l-lunak-5)]

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

[L-lunak-5 (l-lunak-5)]

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

[Y-coolo (y-coolo)]

Replaced <email address hidden> with <email address hidden> due to bounces by reporter

[L-lunak-5 (l-lunak-5)]

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

[L-lunak-5 (l-lunak-5)]

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

[L-lunak-5 (l-lunak-5)]

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

[hbush (harijs)]

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.

[sulla (wolfgang-sailer)]

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

[Stefan-borggraefe (stefan-borggraefe)]

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

[Kyromaster (kyromaster)]

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.

[Kde-8 (kde-8)]

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

[L-lunak-5 (l-lunak-5)]

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.

[usr (usrlp-deactivatedaccount-deactivatedaccount)]

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

[kioftes (thstyl2000)]

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

[Z-lucas (z-lucas)]

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

[Harald Sitter (apachelogger)]

Rejecting for kubuntu-default-settings since upstream needs to accept this as default, also from a general point of view, not the window manager should remember the position and size, but the application, thus being wm-agnostic.

Moving to kdebase-workspace waiting on upstream action.

[Jonathan Thomas (echidnaman)]

Hi there,
We are in the process of closing wishlist items that have already been reported at KDE. Don't worry, your issue still is being tracked at KDE's bug tracker at: http://bugs.kde.org/show_bug.cgi?id=15329 . It's just that Kubuntu currently does not have the manpower necessary to take this feature on ourselves. We will receive this functionality once KDE implements it in one of their releases.

Thanks for understanding, and have a nice day.

[Nemeskey-david (nemeskey-david)]

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.

[Gökdeniz Karadağ (gokdeniz)]

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.

[Thomas-luebking (thomas-luebking)]

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

[Hormel (hormel)]

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.

[Mgraesslin (mgraesslin)]

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

[Thomas-luebking (thomas-luebking)]

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)

[Hormel (hormel)]

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. :)

[Hormel (hormel)]

(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 operatio...

[Mgraesslin (mgraesslin)]

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

[Hormel (hormel)]

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

[Thomas-luebking (thomas-luebking)]

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

[Hormel (hormel)]

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

[Mgraesslin (mgraesslin)]

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.

[Thomas-luebking (thomas-luebking)]

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

[Nate-b (nate-b)]

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

[Qik00 (qik00)]

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

[Nemeskey-david (nemeskey-david)]

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

[Nate-b (nate-b)]

(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. :)

[Nate-b (nate-b)]

(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. ;)

[Qik00 (qik00)]

(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

[Nate-b (nate-b)]

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.

[Nate-b (nate-b)]

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

[Bartoloni-f (bartoloni-f)]

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

[Nate-b (nate-b)]

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

[Nate-b (nate-b)]

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

[Nate-b (nate-b)]

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

[Nate-b (nate-b)]

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

[Strangiato Xanadu (strangiato)]

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

[pieter k (pieterkristensen)]

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.

[pieter k (pieterkristensen)]

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.

[Nate-b (nate-b)]

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

[Strangiato Xanadu (strangiato)]

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

[sulla (wolfgang-sailer)]

all right, we've just crossed the 22-year line on this bug.
I'm out.
;-)

[Bingmybong (bingmybong)]

Never had an issue with this under X and nouveau but have it now using Wayland with radeon

[Gannet (ken20001)]

2023 is on the street, and it is impossible to switch between the windows of Wayland and XWayland.

[Nate-b (nate-b)]

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

[Nate-b (nate-b)]

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

[Raman Gupta (rocketraman)]

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.

[Nate-b (nate-b)]

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.

[Gannet (ken20001)]

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

[Xaver Hugl (xaver-hugl)]

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

[Xaver Hugl (xaver-hugl)]

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

[nullsteph (p-stephenwille)]

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

[Xaver Hugl (xaver-hugl)]

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

[Piotr-mierzwinski (piotr-mierzwinski)]

I case of restore Plasma session if you use one monitor then all windows are placed in the middle of screen on the stack. IMO, this is not so elegant and convenient, because user after that need to/usually want rearrange/place them in way like were placed in previous session.

About save position.
I think setting rules to given window to save its position would be saved isn't easy for regular user. In my opinion easiest would be put option into window's properties. I mean icon at the left top corner if window and its menu, where is placed entry "More options" and here "Move", "Resize", "Full Screen", e.t.c.. And here would be good to put here option like "Save my position".

[Alanjprescott (alanjprescott)]

The whole restore from manually saved session seems to be out of kilter under Plasma6/Wayland.
The set up I've been using previously is 8 Desktops with Dolphin on 1, Konsole on 5 and Firefox on 7, all set to to show on All Activities and in the positions I want. At the moment the only app that opens is Firefox and that on Desktop 1, in the middle of the Desktop and only available in the current activity.

Operating System: openSUSE Tumbleweed 20240319
KDE Plasma Version: 6.0.2
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2
Kernel Version: 6.8.1-1-default (64-bit)
Graphics Platform: Wayland

[Nate-b (nate-b)]

Session restore is unrelated to this feature request.

[Alanjprescott (alanjprescott)]

Created attachment 167611
attachment-839626-0.html

What Classification and Product should I report session restore bugs in?
I'd rather not use "I don't know" if there's something more accurate

Alan Prescott
<email address hidden>

On Fri, 22 Mar 2024 at 16:00, Nate Graham <email address hidden> wrote:

> https://bugs.kde.org/show_bug.cgi?id=15329
>
> --- Comment #90 from Nate Graham <email address hidden> ---
> Session restore is unrelated to this feature request.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Nate-b (nate-b)]

plasmashell | Session Management would be the place.

[Ad-liu-jin (ad-liu-jin)]

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

[Raman Gupta (rocketraman)]

(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

[Nate-b (nate-b)]

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

[Raman Gupta (rocketraman)]

(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

[simon_C (dragoncast)]

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?

[Pifuzi (pifuzi)]

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.