15329 2000-11-14 13:48:02 +0000 Use Wayland session restore to save and remember size, position, virtual desktop, etc. of windows of session-restore-compatible apps 2026-02-23 13:00:26 +0000 1 1 4 Plasma kwin general 5.26.5 unspecified Linux CONFIRMED https://bugs.kde.org/show_bug.cgi?id=436318 https://bugs.kde.org/show_bug.cgi?id=487912 https://bugs.kde.org/show_bug.cgi?id=442192 https://bugs.kde.org/show_bug.cgi?id=482816 https://bugs.kde.org/show_bug.cgi?id=515711 usability, wayland-only VHI wishlist --- 510929 1 abrahams kwin-bugs-null 4wy78uwh 60f31543-f82f-492a-8430-25db5521568b abakumov.alexandr achilleas.k adem4ik adorkablue1996 agurenko al.neodim alanjprescott ancoron.luciferis anton.schenker aoeui arisu+kdebugs artem.anufrij az.dev barry bartoloni bernie bingmybong bobofenglish bohlke breakingspell bryan bugs.kde.org bugs.kde.org bugs.kde.pistos bugs.kde bugseforuns butirsky cabanur caerulean.trigon claudius.ellsel codermotor dagda dang dashonwwIII ddascalescu+kde dennis devguy.ca dion dkxls23 dragoncast drew.m.fisher e.duisters1 enc0re endymion+kde eugene.savitsky forums.basil562 frederick888 fridolin.411 gabravier grahamperrin guido.iodice harijs herzenschein hormel hueponik irgend-kdebugs ismail itsforspam99 izylstra j.cook jason.boissiere jlp kairo katze_942 kde-bugs kde-bugs kde.bugs kde.stimulate395 kde kde KDE kde kde kdebugsq kdedev ken20001 kontakt kustodian L.Bonnaud lapo lencho linux_rulez lomaharshana m.busico m.kurz madLyfe madness742 maiphi.public majoroversight manuelchaves matthias.schrumpf mavericfso+kde mberezin+bugskde med.medin.2014 miguel miranda monkiki mrmazda musikolo mwmj2hr4u natalie_clarius nate nemeskey.david nerumo nick niklassalminen nucleo null oded odzinic omosnacek p.r.worrall p.stephenwille petr pieterkristensen pietromrl0 piotr.mierzwinski pm pmrpla+bugskde poperigby postix praedor r.lehmeier r2b2x3+kdebug rainer.meier ranky rimuatkinson rocketraman s.roussak sam scottn sdar sebi.loew silver.salonen slaout smowtenshi spamless.9v5xj t.p.northover the.real.samuel.jimenez thierry.walter3 thstyl2000 tneo travneff twelho unix1 usrrgt ville.aakko web whyhow+tech xdata xnwrsp yellow.cat87355 zawertun zzrakic 0 oldest_to_newest 14405 0 kidcat7 2000-11-14 13:42:45 +0000 (*** 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) 96117 1 l.lunak 2002-09-26 19:44:57 +0000 *** Bug 27969 has been marked as a duplicate of this bug. *** 97102 2 l.lunak 2002-10-01 12:18:19 +0000 *** Bug 18578 has been marked as a duplicate of this bug. *** 97401 3 l.lunak 2002-10-02 17:37:51 +0000 See also bug #39946. 100661 4 harijs 2002-10-19 22:18:47 +0000 > 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. 110158 5 l.lunak 2002-12-19 19:54:32 +0000 *** Bug 28224 has been marked as a duplicate of this bug. *** 135163 6 l.lunak 2003-05-22 15:45:16 +0000 *** Bug 58771 has been marked as a duplicate of this bug. *** 169357 7 slaout 2003-10-27 13:04:04 +0000 - 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 ? 222634 8 l.lunak 2004-04-09 23:21:22 +0000 *** Bug 79300 has been marked as a duplicate of this bug. *** 232283 9 l.lunak 2004-05-13 11:27:43 +0000 *** Bug 81463 has been marked as a duplicate of this bug. *** 233664 10 coolo 2004-05-17 20:11:09 +0000 Replaced kidcat7@hotmail.com with abrahams@acm.org due to bounces by reporter 306747 11 l.lunak 2005-01-25 12:52:22 +0000 *** Bug 85715 has been marked as a duplicate of this bug. *** 306749 12 l.lunak 2005-01-25 12:52:29 +0000 *** Bug 97718 has been marked as a duplicate of this bug. *** 306750 13 l.lunak 2005-01-25 12:53:42 +0000 NOTE TO SELF: Check all duplicates, especially the last two. 311833 14 harijs 2005-02-09 12:53:52 +0000 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. 449205 15 Wolfgang 2006-06-23 20:16:13 +0000 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...) 452869 16 Stefan.Borggraefe 2006-07-11 17:32:09 +0000 *** Bug 121736 has been marked as a duplicate of this bug. *** 452880 17 kontakt 2006-07-11 18:02:32 +0000 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. 482284 18 kde 2006-11-02 02:55:48 +0000 > 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. 484586 19 l.lunak 2006-11-06 12:54:22 +0000 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. 675573 20 usrrgt 2008-12-05 02:26:54 +0000 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). 697684 21 thstyl2000 2009-01-11 11:30:47 +0000 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 751418 22 lucas 2009-05-03 04:48:56 +0000 *** Bug 191375 has been marked as a duplicate of this bug. *** 1054664 23 nemeskey.david 2010-12-07 08:15:14 +0000 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. 1208953 24 gokdenizk 2012-01-04 04:46:29 +0000 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. 1209186 25 thomas.luebking 2012-01-04 15:04:25 +0000 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. 1215882 26 hormel 2012-01-18 05:08:00 +0000 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. 1215884 27 mgraesslin 2012-01-18 05:28:31 +0000 > 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. 1215888 28 thomas.luebking 2012-01-18 05:55:18 +0000 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) 1215889 29 hormel 2012-01-18 05:57:41 +0000 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. :) 1215891 30 hormel 2012-01-18 06:38:51 +0000 (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. 1215895 31 mgraesslin 2012-01-18 07:15:12 +0000 > (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. 1215899 32 hormel 2012-01-18 07:37:09 +0000 > 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. 1216070 33 thomas.luebking 2012-01-18 16:24:13 +0000 (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) 1216574 34 hormel 2012-01-19 20:25:45 +0000 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 1234623 35 mgraesslin 2012-03-10 15:23:03 +0000 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. 1236615 36 thomas.luebking 2012-03-14 22:38:57 +0000 *** Bug 192060 has been marked as a duplicate of this bug. *** 1877469 37 nate 2019-08-28 15:26:48 +0000 *** Bug 380799 has been marked as a duplicate of this bug. *** 1877471 38 nate 2019-08-28 15:26:56 +0000 *** Bug 384091 has been marked as a duplicate of this bug. *** 1877477 39 nate 2019-08-28 15:31:09 +0000 *** Bug 409349 has been marked as a duplicate of this bug. *** 1877479 40 nate 2019-08-28 15:31:10 +0000 *** Bug 409338 has been marked as a duplicate of this bug. *** 1877481 41 nate 2019-08-28 15:34:59 +0000 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. 1877521 42 mgraesslin 2019-08-28 20:11:17 +0000 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. 1943520 43 nate 2020-07-13 18:11:40 +0000 *** Bug 424162 has been marked as a duplicate of this bug. *** 1943521 44 nate 2020-07-13 18:13:15 +0000 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. 1943557 45 kde 2020-07-13 19:35:12 +0000 Just to set expectations it's when that lands upstream, and we implement it and every client also implements what is relevant. 1943604 46 null 2020-07-13 21:59:05 +0000 (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. 1943611 47 nate 2020-07-13 22:15:26 +0000 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. 1943924 48 null 2020-07-15 01:17:09 +0000 (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. 1944048 49 null 2020-07-15 17:47:06 +0000 (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. 1944097 50 null 2020-07-15 20:36:04 +0000 *** Bug 424257 has been marked as a duplicate of this bug. *** 1944141 51 nate 2020-07-16 02:27:51 +0000 (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? 1944173 52 vlad.zahorodnii 2020-07-16 06:22:44 +0000 (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. 1944178 53 vlad.zahorodnii 2020-07-16 06:25:32 +0000 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. 1944214 54 Wolfgang 2020-07-16 09:42:26 +0000 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 1944252 55 cfeck 2020-07-16 14:04:02 +0000 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? 1944265 56 nemeskey.david 2020-07-16 14:38:51 +0000 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). 1944275 57 cfeck 2020-07-16 15:16:31 +0000 This isn't about recognizing the issue, but solving it. 1944278 58 nate 2020-07-16 15:19:44 +0000 (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. 1944338 59 null 2020-07-16 19:06:38 +0000 (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 ? 1944350 60 nemeskey.david 2020-07-16 19:41:06 +0000 (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. 1944369 61 nate 2020-07-16 20:27:06 +0000 (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. :) 1944371 62 nate 2020-07-16 20:30:13 +0000 (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. ;) 1944513 63 null 2020-07-17 14:13:25 +0000 (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 1951999 64 nate 2020-08-20 17:00:48 +0000 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. 1976792 65 nate 2020-11-19 20:37:44 +0000 *** Bug 429361 has been marked as a duplicate of this bug. *** 1982227 66 bartoloni 2020-12-07 09:31:27 +0000 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 1982294 67 nate 2020-12-07 15:21:08 +0000 That's not related to this issue and is already tracked with Bug 429943. 2008000 68 nate 2021-03-02 19:03:25 +0000 *** Bug 433836 has been marked as a duplicate of this bug. *** 2022361 69 nate 2021-04-05 00:36:40 +0000 *** Bug 435357 has been marked as a duplicate of this bug. *** 2026680 70 nate 2021-04-21 19:51:33 +0000 *** Bug 435914 has been marked as a duplicate of this bug. *** 2040430 71 bugseforuns 2021-06-14 13:41:03 +0000 *** Bug 438599 has been marked as a duplicate of this bug. *** 2050358 72 pieterkristensen 2021-08-02 09:14:16 +0000 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. 2050638 73 pieterkristensen 2021-08-03 04:23:06 +0000 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. 2112158 74 nate 2022-03-20 14:20:58 +0000 *** Bug 450806 has been marked as a duplicate of this bug. *** 2161550 75 bugseforuns 2022-10-15 20:00:26 +0000 *** Bug 460498 has been marked as a duplicate of this bug. *** 2174439 76 Wolfgang 2022-11-17 20:28:57 +0000 all right, we've just crossed the 22-year line on this bug. I'm out. ;-) 2178457 77 bingmybong 2022-11-28 14:39:28 +0000 Never had an issue with this under X and nouveau but have it now using Wayland with radeon 2206761 78 ken20001 2023-02-10 22:12:28 +0000 2023 is on the street, and it is impossible to switch between the windows of Wayland and XWayland. 2231939 79 nate 2023-05-19 20:12:01 +0000 *** Bug 469987 has been marked as a duplicate of this bug. *** 2234048 80 nate 2023-05-31 19:08:13 +0000 *** Bug 470318 has been marked as a duplicate of this bug. *** 2234061 81 rocketraman 2023-05-31 20:00:36 +0000 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. 2234063 82 nate 2023-05-31 20:02:39 +0000 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. 2234079 83 ken20001 2023-05-31 21:27:20 +0000 (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. 2239936 84 xaver.hugl 2023-07-06 15:26:44 +0000 *** Bug 471996 has been marked as a duplicate of this bug. *** 2243621 85 xaver.hugl 2023-07-31 12:43:37 +0000 *** Bug 472818 has been marked as a duplicate of this bug. *** 2279425 86 p.stephenwille 2024-01-11 15:15:56 +0000 Same issue. Need all apps to assume their last known position on start and when monitors are removed/added. 2288004 87 xaver.hugl 2024-02-11 16:59:57 +0000 *** Bug 481193 has been marked as a duplicate of this bug. *** 2292748 88 piotr.mierzwinski 2024-02-29 10:04:27 +0000 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". 2304113 89 alanjprescott 2024-03-22 10:40:46 +0000 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 2304194 90 nate 2024-03-22 14:00:11 +0000 Session restore is unrelated to this feature request. 2304212 91 167611 alanjprescott 2024-03-22 15:02:04 +0000 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 alanjprescott@gmail.com On Fri, 22 Mar 2024 at 16:00, Nate Graham <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=15329 > > --- Comment #90 from Nate Graham <nate@kde.org> --- > Session restore is unrelated to this feature request. > > -- > You are receiving this mail because: > You are on the CC list for the bug. 2304455 92 nate 2024-03-23 04:26:24 +0000 plasmashell | Session Management would be the place. 2304486 93 ad.liu.jin 2024-03-23 09:40:13 +0000 *** Bug 484305 has been marked as a duplicate of this bug. *** 2331192 94 rocketraman 2024-06-24 13:21:11 +0000 (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 2336362 95 nate 2024-07-10 20:06:49 +0000 *** Bug 489248 has been marked as a duplicate of this bug. *** 2336375 96 rocketraman 2024-07-10 20:23:42 +0000 (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 2338043 97 dragoncast 2024-07-17 20:02:02 +0000 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? 2347491 98 forums.basil562 2024-08-21 16:44:16 +0000 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. 2360876 99 kde-bugs 2024-09-29 10:23:50 +0000 (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. 2362302 100 rocketraman 2024-10-03 12:40:39 +0000 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? 2362310 101 eugene.savitsky 2024-10-03 13:54:31 +0000 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... 2363236 102 oded 2024-10-06 14:29:52 +0000 (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. 2365220 103 sebi.loew 2024-10-12 13:15:02 +0000 I can confirm, this bug is really annoying after each restart. 2365443 104 enc0re 2024-10-13 09:47:23 +0000 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. 2365460 105 eugene.savitsky 2024-10-13 11:20:50 +0000 Just tested. Dolphin and Konsole do remember size, but not position, they always open centered (if were not maximized) on a one screen system. 2365650 106 kde-bugs 2024-10-14 01:10:00 +0000 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. 2386682 107 rainer.meier 2025-01-04 00:13:33 +0000 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. 2410954 108 kdedev 2025-03-26 21:45:15 +0000 *** Bug 500958 has been marked as a duplicate of this bug. *** 2420499 109 strong.drum0546 2025-05-01 22:38:34 +0000 *** Bug 503446 has been marked as a duplicate of this bug. *** 2429283 110 caerulean.trigon 2025-05-31 10:23:16 +0000 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 2429675 111 xaver.hugl 2025-06-02 12:56:13 +0000 *** Bug 479391 has been marked as a duplicate of this bug. *** 2430256 112 bugs.kde.pistos 2025-06-04 14:59:07 +0000 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 2430280 113 eugene.savitsky 2025-06-04 15:53:44 +0000 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. 2435205 114 bobofenglish 2025-06-23 04:16:43 +0000 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. 2435440 115 forums.basil562 2025-06-23 16:10:37 +0000 Absolutely, agree with everyone who says this feature should be in KDE. Quite candidly, the entire landscape feels so amateurish and puerile to me. All this discussion about people writing scripts (in various scripting languages) to make ad hoc and somewhat band-aided "solutions" wreaks of amateur night--not ready for prime time. If this feature cannot be implemented easily, then KDE (and the entire Linux platform for that matter) needs some serious architecture... and serious, experienced, seasoned architects.... I find it pretty disillusioning that Linux still doesn't do so many things that my SunOS / OpenLook desktop did nicely in 1988.... 2435457 116 4wy78uwh 2025-06-23 16:48:13 +0000 (In reply to Vartan from comment #115) > I find it pretty disillusioning that Linux still doesn't do so many things that my SunOS / OpenLook desktop did nicely in 1988.... They didn't architect their OS for multiple DEs that *already* exist. This would be a comparably trivial endeavour for the KDE developers to implement themselves if their stack were as monolithic as macOS or Windows 11's are. One cannot have standardisation, a quick release, and universal support simultaneously. 2435483 117 forums.basil562 2025-06-23 17:53:53 +0000 (In reply to Roke Julian Lockhart Beedell from comment #116) > (In reply to Vartan from comment #115) > > > I find it pretty disillusioning that Linux still doesn't do so many things that my SunOS / OpenLook desktop did nicely in 1988.... > > They didn't architect their OS for multiple DEs that *already* exist. This > would be a comparably trivial endeavour for the KDE developers to implement > themselves if their stack were as monolithic as macOS or Windows 11's are. > One cannot have standardisation, a quick release, and universal support > simultaneously. Architecture does not imply "monolithic" anything -- in fact, quite the opposite. 2435533 118 4wy78uwh 2025-06-23 19:24:32 +0000 (In reply to Vartan from comment #117) Why have you said that? A single word can't imply anything. 2435554 119 bobofenglish 2025-06-23 20:40:28 +0000 (In reply to Vartan from comment #115) > Absolutely, agree with everyone who says this feature should be in KDE. > > Quite candidly, the entire landscape feels so amateurish and puerile to me. > All this discussion about people writing scripts (in various scripting > languages) to make ad hoc and somewhat band-aided "solutions" wreaks of > amateur night--not ready for prime time. > > If this feature cannot be implemented easily, then KDE (and the entire Linux > platform for that matter) needs some serious architecture... and serious, > experienced, seasoned architects.... > > I find it pretty disillusioning that Linux still doesn't do so many things > that my SunOS / OpenLook desktop did nicely in 1988.... If it's not a problem of KDE's making, then why are you blaming them and building a strawman argument? If the Linux community is incompetent, then on account that you can download the source files and do with them as you wish for the most part, get coding, and show us how it's done! Of course you could always just educate yourself about the differences between corporations and all the resources they can throw at things like what you are looking for but don't feel any obligation to satisfy users needs and wishes, and a world wide community contributing to millions of projects to give everyone what they need and want best they can and against all odds have made it well worth ditching that POS Windows for! Oh, and they actually listen to us here, especially the KDE people! They are unbeaten in my book! Linux runs somewhere over 75% of the world, so all the stuff no one in their right mind would trust with Windows or even MacOS! Linux is everywhere, even outer space! Linux is taking over the world! You have other choices if you wish. You may want to try one of the BSD's, Haiku... or maybe you are more of a Temple OS person? 2435559 120 grahamperrin 2025-06-23 20:57:43 +0000 I have close to zero tolerance for people who misuse Bugzilla. This is not a discussion forum. 2435576 121 4wy78uwh 2025-06-23 22:02:18 +0000 (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. 2446236 122 sdar 2025-08-09 15:59:46 +0000 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. 2446237 123 4wy78uwh 2025-08-09 16:04:01 +0000 (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. 2446541 124 kdedev 2025-08-11 16:28:32 +0000 *** Bug 503790 has been marked as a duplicate of this bug. *** 2460655 125 kde 2025-10-09 12:59:00 +0000 *** Bug 510393 has been marked as a duplicate of this bug. *** 2461640 126 kde 2025-10-13 17:23:28 +0000 *** Bug 510566 has been marked as a duplicate of this bug. *** 2463889 127 nate 2025-10-22 19:34:15 +0000 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. 2463893 128 nate 2025-10-22 19:43:17 +0000 *** Bug 496674 has been marked as a duplicate of this bug. *** 2463910 129 nate 2025-10-22 19:51:24 +0000 *** Bug 482816 has been marked as a duplicate of this bug. *** 2463912 130 nate 2025-10-22 19:51:33 +0000 *** Bug 484318 has been marked as a duplicate of this bug. *** 2463914 131 nate 2025-10-22 19:51:35 +0000 *** Bug 496063 has been marked as a duplicate of this bug. *** 2463926 132 nate 2025-10-22 20:08:03 +0000 *** Bug 499842 has been marked as a duplicate of this bug. *** 2463928 133 nate 2025-10-22 20:08:42 +0000 *** Bug 428864 has been marked as a duplicate of this bug. *** 2463957 134 4wy78uwh 2025-10-22 21:09:44 +0000 (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. 2463987 135 nate 2025-10-22 22:12:38 +0000 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. 2463989 136 dragoncast 2025-10-22 22:34:59 +0000 (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. 2464001 137 bobofenglish 2025-10-23 00:03:45 +0000 (In reply to Nate Graham from comment #135) > 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. Something tells me they could, and should though, as well as all making apps for all DE's, and as a superpower user with no developing skills but most basic HTML, CSS, and of course just enough Bash command language to use the terminal with notes and stuff open to help me not mess up. I am allthough very understanding of it all on a more conceptual level, an electronics engineer who made science grade Wave tech for R&D, like spectroscopy... and logic circuitry, and so in using computers since 1979, and what many of us understood what computers were capable of, and should do, how best to do it... and watched it go sideways anyhow, often mostly not for the better with big tech, and so I do have a good idea I'm sure others have thought of too, in order to fix a lot of stuff similar as to interoperability and so, more of a Linux standard procedure, than a specific module, with some and the idea based on some Star Trek tech, but also what already is done in ways within programs, I will for now call: "universal translator files". Just comma, line, glyph type lists and yes small programs and what not, but in basic a go between to translate stuff that differ in programing languages, but do essentially the same thing, but differing based on the differing methods those languages and modules do them: Example: All KDE apps can go through it to pass it's commands... to the translator, and it translates it to gnome, and all DEs to one and it to all compositors... that way without unifying Linux by using only one compositor and DE, like a monolith, still behave like one no matter what DE, compositor, apps are in use with fewer issues. The how I cannot help with much other than in concept, but if, and then once it is more like a project in development, I can help, at least with some pretty good critical and rational thinking skills. I know it doesn't quite help here and now, but it came to mind, and I think may be worthy for consideration, and if so should be addressed on a more general entity level, so maybe The FSF, Kernel developer space or wherever most appropriate, and I can hit them up on it once I know the best place to start, and who to run it by Some of it actually already exists; I'm sure, but it just needs to be in more of a standards and compliance (hated but helps) way, so any tips and feedback on that would be appreciated. And once in swing Ill get on trying to tackle my love hate relationship with most if not all spell checkers. ;>) 2465395 138 dennis 2025-10-26 22:36:40 +0000 (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! 2468605 139 pieterkristensen 2025-11-07 08:22:26 +0000 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... 2468624 140 achilleas.k 2025-11-07 10:50:30 +0000 (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 2468654 141 miguel 2025-11-07 12:32:34 +0000 (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. 2468659 142 pmrpla+bugskde 2025-11-07 12:39:54 +0000 (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. 2468670 143 4wy78uwh 2025-11-07 12:54:57 +0000 (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. 2468699 144 kde 2025-11-07 15:55:47 +0000 (In reply to Nate Graham from comment #127) > So I'm afraid the dream of "remember all window positions automatically without apps having to do > anything" is dead, sorry. Kidding? This draws wayland DOA. For years and years I read news about wayland becoming the new default. Every time I tried it instantly crashed (what about live kernel patching, BTW... also standard for as long as Elon's FSD). For about a year it's actually stable as a daily driver. But it's still not able to even place windows on the proper virtual desktop! Dafuq?! Consider yourself lucky that it can resize windows!11!! What is this? A call to switch to the Mac for good?! We will have hoverboard before wayland is going to be usable as a product. 2468706 145 4wy78uwh 2025-11-07 16:34:59 +0000 (In reply to Timo Nentwig from comment #144) That's disingenuous. He elaborated well in https://bugs.kde.org/show_bug.cgi?id=15329#c135. 2468709 146 forums.basil562 2025-11-07 16:52:46 +0000 (In reply to Timo Nentwig from comment #144) > (In reply to Nate Graham from comment #127) > > So I'm afraid the dream of "remember all window positions automatically without apps having to do > > anything" is dead, sorry. > > Kidding? This draws wayland DOA. > > For years and years I read news about wayland becoming the new default. > Every time I tried it instantly crashed (what about live kernel patching, > BTW... also standard for as long as Elon's FSD). For about a year it's > actually stable as a daily driver. But it's still not able to even place > windows on the proper virtual desktop! Dafuq?! Consider yourself lucky that > it can resize windows!11!! > > What is this? A call to switch to the Mac for good?! > > We will have hoverboard before wayland is going to be usable as a product. The problem with Linux is that there is no coordination or alignment across all the projects.... And there is no real architecture effort to speak of.... And the people running these projects don't want the input of people who built the Unix systems of the 80s and 90s.... They think they know better. I just might end up switching back to Mac. People talk about its risks. But one can mitigate a lot of risk by using more trustworthy tools such as Thunderbird mail client, a reputable VPN, and so forth. I've not read anything conclusive (a lot of speculation, but no confirmation) that macOS is actually logging keystrokes or doing the draconian things that Windows 11 does (which are confirmed). Very sad.... SunOS Open Look in 1990 worked like a dream... desktop, any of a number of your choice of window managers... 'cause it was well architected by professionals... The Common Desktop Environment (CDE) and Motif were also good... at least they worked and did all the things that Linux today still can't do. Yeah, I'm sure my comment will be deleted by the moderators... 2468713 147 bernie 2025-11-07 17:25:11 +0000 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. 2468722 148 postix 2025-11-07 17:35:25 +0000 This is a bug tracker, not a forum! Please move this discussion to https://discuss.kde.org or elsewhere more appropriate. 2495239 149 guido.iodice 2026-02-16 18:34:20 +0000 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? 2495260 150 forums.basil562 2026-02-16 20:12:04 +0000 (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.... 2496430 151 nate 2026-02-19 23:08:04 +0000 (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. 2496644 152 guido.iodice 2026-02-20 14:34:39 +0000 (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? 2496648 153 guido.iodice 2026-02-20 14:40:47 +0000 (In reply to Vartan from comment #150) > 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.... The session restore works for me, I don't know if it is the "fake" one or the "true" one. 2496655 154 r.lehmeier 2026-02-20 15:01:26 +0000 Does it work across different activities, or do you use the X11 variant of Plasma? 2496657 155 guido.iodice 2026-02-20 15:04:14 +0000 (In reply to Lehmeier from comment #154) > Does it work across different activities, or do you use the X11 variant of > Plasma? Yes, I was talking about Wayland. Honestly, I don't use activities. 2496663 156 nate 2026-02-20 15:30:23 +0000 (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. 2496693 157 r.lehmeier 2026-02-20 16:24:01 +0000 It's hard to believe that 26 years have passed since this error message appeared, and Wayland still considers this feature experimental? Make sure it works, and applications will implement it. Why should applications implement a feature that they themselves describe as experimental rather than fundamental? 2496704 158 guido.iodice 2026-02-20 16:52:34 +0000 (In reply to Lehmeier from comment #157) > It's hard to believe that 26 years have passed since this error message > appeared, and Wayland still considers this feature experimental? > > Make sure it works, and applications will implement it. > Why should applications implement a feature that they themselves describe as > experimental rather than fundamental? Wayland is dated, but not that dated. This bug has been recycled for some reason, but it dates back to KDE 3. In any case, Wayland is now 18 yo, I also believe that they are old enough to implement at least the basic functions of other desktop systems. 2496752 159 r.lehmeier 2026-02-20 18:03:49 +0000 As I see it, after 18 years, it should be able to do more than just the basic functions. If everyone is supposed to/wants to switch to it, then it should be possible to use it to its full potential and not point out that important functions are only experimental. Then maybe I should go back to X11 after all. Session restoration has supposedly been working there again for about 6 months. 2496785 160 linux_rulez 2026-02-20 19:26:55 +0000 We're far from Wayland ready and I have serious concerns about the end of support of X11. 2496811 161 guido.iodice 2026-02-20 20:31:52 +0000 (In reply to Lehmeier from comment #159) > As I see it, after 18 years, it should be able to do more than just the > basic functions. (In reply to kaminata from comment #160) > We're far from Wayland ready and I have serious concerns about the end of > support of X11. I agree. But this is no accident; it's part of Wayland's history and its current development. Wayland was always primarily designed for embedded/entertainment systems. So not for the desktop. This explains why the protocol we are discussing is still experimental despite being an almost basic feature for a desktop system, while the protocol for tablets has been merged 10 years ago, and HDR is already in the staging phase, even though it is not essential on the desktop but is for entertainment systems. 2496899 162 nate 2026-02-21 02:20:52 +0000 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! 2496974 163 r.lehmeier 2026-02-21 08:48:00 +0000 I don't want to complain, but I would like to make it clear that Wayland should not be installed if it does not have the necessary functions on board. It is always presented as if Wayland were the ultimate solution, but it has not even made it past the beta stage—at least in terms of the required range of functions. This should be a priority for further development. 2497573 164 ahiemstra 2026-02-23 13:00:26 +0000 *** Bug 516471 has been marked as a duplicate of this bug. *** 167611 2024-03-22 15:02:07 +0000 2024-03-22 15:02:07 +0000 attachment-839626-0.html attachment-839626-0.html text/html 1199 alanjprescott PGRpdiBkaXI9Imx0ciI+PGRpdj5XaGF0IENsYXNzaWZpY2F0aW9uIGFuZCBQcm9kdWN0IHNob3Vs ZCBJIHJlcG9ydCBzZXNzaW9uIHJlc3RvcmUgYnVncyBpbj88L2Rpdj48ZGl2PkkmIzM5O2QgcmF0 aGVyIG5vdCB1c2UgJnF1b3Q7SSBkb24mIzM5O3Qga25vdyZxdW90OyBpZiB0aGVyZSYjMzk7cyBz b21ldGhpbmcgbW9yZSBhY2N1cmF0ZTxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjxkaXY+ PGRpdiBkaXI9Imx0ciIgY2xhc3M9ImdtYWlsX3NpZ25hdHVyZSIgZGF0YS1zbWFydG1haWw9Imdt YWlsX3NpZ25hdHVyZSI+PGRpdj5BbGFuIFByZXNjb3R0PC9kaXY+DQo8ZGl2PjxhIGhyZWY9Im1h aWx0bzphbGFuanByZXNjb3R0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFsYW5qcHJlc2Nv dHRAZ21haWwuY29tPC9hPjwvZGl2PjwvZGl2PjwvZGl2Pjxicj48L2Rpdj48L2Rpdj48YnI+PGRp diBjbGFzcz0iZ21haWxfcXVvdGUiPjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9hdHRyIj5P biBGcmksIDIyIE1hciAyMDI0IGF0IDE2OjAwLCBOYXRlIEdyYWhhbSAmbHQ7PGEgaHJlZj0ibWFp bHRvOmJ1Z3ppbGxhX25vcmVwbHlAa2RlLm9yZyI+YnVnemlsbGFfbm9yZXBseUBrZGUub3JnPC9h PiZndDsgd3JvdGU6PGJyPjwvZGl2PjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5 bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIw NCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij48YSBocmVmPSJodHRwczovL2J1Z3Mua2RlLm9y Zy9zaG93X2J1Zy5jZ2k/aWQ9MTUzMjkiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vYnVncy5rZGUub3JnL3Nob3dfYnVnLmNnaT9pZD0xNTMyOTwvYT48YnI+DQo8YnI+ DQotLS0gQ29tbWVudCAjOTAgZnJvbSBOYXRlIEdyYWhhbSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5h dGVAa2RlLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5hdGVAa2RlLm9yZzwvYT4mZ3Q7IC0tLTxicj4N ClNlc3Npb24gcmVzdG9yZSBpcyB1bnJlbGF0ZWQgdG8gdGhpcyBmZWF0dXJlIHJlcXVlc3QuPGJy Pg0KPGJyPg0KLS0gPGJyPg0KWW91IGFyZSByZWNlaXZpbmcgdGhpcyBtYWlsIGJlY2F1c2U6PGJy Pg0KWW91IGFyZSBvbiB0aGUgQ0MgbGlzdCBmb3IgdGhlIGJ1Zy48L2Jsb2NrcXVvdGU+PC9kaXY+ DQo=