Bug 427875

Summary: On a multi screen setup, KDE app windows do not remember size, position, or the screen they were last opened on. For X11 when the left-most display is not the primary one.
Product: [Frameworks and Libraries] frameworks-kconfig Reporter: Claudius Ellsel <claudius.ellsel>
Component: generalAssignee: Nate Graham <nate>
Status: RESOLVED FIXED    
Severity: normal CC: 76qr6azg, aspotashev, brassman, bugs.kde, daniel.swarbrick, david.alejandro.rubio, Deckweiss75, devguy.ca, dkxls23, f.baumg, friedrich.schriewer, georgefb899, giggi1999, hans, hexer504, hugor.hugolin, isma.af, jan.claussen10, jhs, jjj65creed, kaeslaek, kde.kfoar, kde, kde, kde, kdelibs-bugs, lands.wilmoth, loveisgrief, marco.ambu, martin, mosaulp, myndstream, nate, neuromancerx1, piotr.mierzwinski, popov895, postix, prettyvanilla, realdude1, ricardo.steijn97, sannythebest95, sephiroth_pk, shawn.peterson, slartibart70, smit17xp, smtea923, tomashnyk, viktor_jaegerskuepper, vlad.zahorodnii, xnwrsp
Priority: VHI Keywords: multiscreen, regression, usability
Version: 5.80.0   
Target Milestone: ---   
Platform: Manjaro   
OS: Linux   
See Also: https://bugs.kde.org/show_bug.cgi?id=378896
https://bugs.kde.org/show_bug.cgi?id=460260
Latest Commit: Version Fixed In: 5.99
Attachments: State before closing
State after opening again

Description Claudius Ellsel 2020-10-17 16:29:41 UTC
SUMMARY
-> See title

STEPS TO REPRODUCE
1. Have a multiscreen setup
2. Open Gwenview
3. Move it to the right of both screens
4. (I also maximized it)
5. Close it
6. Open it again

OBSERVED RESULT
It opens (maximized) on the left screen, not the right.

EXPECTED RESULT
It opens where it has been closed before.

SOFTWARE/OS VERSIONS
Operating System: Manjaro Linux
KDE Plasma Version: 5.20.0
KDE Frameworks Version: 5.75.0
Qt Version: 5.15.1
Kernel Version: 5.8.14-1-MANJARO
OS Type: 64-bit
Processors: 4 × Intel® Xeon® CPU E3-1225 v3 @ 3.20GHz
Memory: 11.6 GiB of RAM
Graphics Processor: Mesa DRI Intel® HD Graphics P4600/P4700

ADDITIONAL INFORMATION
Happens on Wayland, not tested on X11.
Comment 1 Claudius Ellsel 2020-10-17 16:34:22 UTC
Created attachment 132484 [details]
State before closing

This screenshot shows the state of Gwenview before closing it
Comment 2 Claudius Ellsel 2020-10-17 16:35:21 UTC
Created attachment 132485 [details]
State after opening again

This screenshot shows the state of Gwenview after opening it again. Expected would be the same as the state before closing, however after opening it again it is on the left screen.
Comment 3 Claudius Ellsel 2020-10-22 15:04:24 UTC
Also happens with Kate for me, so not related to Gwenview alone.
Comment 4 Nate Graham 2020-10-22 15:08:22 UTC
I probably broke this. :(
Comment 5 Claudius Ellsel 2020-10-30 14:11:24 UTC
Does that mean you have an idea of how to fix this? That would be a start :)

Do you think you can fix it until 5.20.3?
Comment 6 Nate Graham 2020-12-07 18:18:22 UTC
*** Bug 428334 has been marked as a duplicate of this bug. ***
Comment 7 Nate Graham 2020-12-07 18:19:28 UTC
*** Bug 430005 has been marked as a duplicate of this bug. ***
Comment 8 Nate Graham 2020-12-07 18:29:39 UTC
My work to fix Bug 415150 has almost certainly caused this.

Unfortunately I'm not sure how to fix it as the screen positioning stuff is something I don't understand well, and non-primary left screens on X11 (the only platform affected) are already known to cause some existing issues. Also I don't have a working multi-screen setup on X11 due to my external screens not matching the resolution my laptop's internal screen and mixed DPI setups on X11 being unusably broken--even more so if I try to position the screen on the left. It's so broken that it kind of feels like a lost cause to try to fix it. :(

Needless to say, assistance would be highly appreciated.
Comment 9 Claudius Ellsel 2020-12-07 19:59:17 UTC
(In reply to Nate Graham from comment #8)
> and non-primary left screens on X11 (the
> only platform affected)

To be clear, this happens on Wayland for me (but I think also on X11).
Comment 10 Nate Graham 2020-12-07 20:04:26 UTC
The feature to remember window sizes and positions using KXMLGui is not used on Wayland.

Remembering window positions on Wayland requires implementing Bug 15329.
Comment 11 Claudius Ellsel 2020-12-07 20:05:42 UTC
I know. I still experience the described bug on Wayland. Maybe not caused by your changes, but it is there.
Comment 12 Salvatore 2020-12-07 20:07:08 UTC
(In reply to Claudius Ellsel from comment #9)
> (In risposta a Nate Graham dal commento n. 8 )
> > e schermate di sinistra non primarie su X11 (il file
> > solo piattaforma interessata)
> 
> Per essere chiari, questo accade su Wayland per me (ma penso anche su X11).

Yes, it also happens on x11
Comment 13 Claudius Ellsel 2020-12-07 20:28:42 UTC
BTW: I might also have been wrong about the multi screen requirement, as I think I also experienced this when disabling a screen on openSUSE Tumbleweed. I might mix up different underlying problems here, though.
Comment 14 Claudius Ellsel 2020-12-07 20:43:00 UTC
(In reply to Claudius Ellsel from comment #13)
> BTW: I might also have been wrong about the multi screen requirement, as I
> think I also experienced this when disabling a screen on openSUSE
> Tumbleweed. I might mix up different underlying problems here, though.

Sorry, ignore that. Mixing things up here. I was talking about a different bug (maximized state not remembered).
Comment 15 Nate Graham 2021-01-14 04:58:37 UTC
*** Bug 431533 has been marked as a duplicate of this bug. ***
Comment 16 Nate Graham 2021-01-14 04:59:34 UTC
Assistance fixing this would be appreciated. I have no idea how to fix it without removing the feature that causes it.
Comment 17 evea 2021-01-14 06:00:39 UTC
I don't think this is related to an added feature. For me this bug has always existed. The only reason the new feature is mentioned, is because people now expected it to work.
Comment 18 Claudius Ellsel 2021-01-14 13:22:14 UTC
*** Bug 431230 has been marked as a duplicate of this bug. ***
Comment 19 Claudius Ellsel 2021-01-14 13:26:12 UTC
The scope of this bug has drifted a bit (it used to be about a bug in Wayland, while now it tracks stuff happening on X11 according to the title). I have marked another bug as a duplicate of this now.

Since this bug has drifted, it might be good to ensure that the original bug scope is not forgotten, but I will probably postpone that until the new scope is fixed.
Comment 20 Claudius Ellsel 2021-01-14 13:34:25 UTC
Playing around a bit, I noticed that when moving windows like Konsole to the left-most display and closing them there, the size gets restored correctly. I can also move the window over to the right primary screen and the newly remembered size gets restored there. Changes to size are not taken into account, though.

So for example I move Konsole to the left screen, resize to 900x600, close it and it is restored correctly. After moving it to the right screen, size remains 900x600. But changing it will always result in 900x600 after opening it again. Changing size again on the left screen to say 800x550 will be remembered. Moving the window again to the right screen and closing will always restore to 800x550.

Hopefully this gets us closer to a solution.
Comment 21 Claudius Ellsel 2021-01-14 15:24:19 UTC
I might have found an explanation to this, although this is just a theory without me having any proper knowledge of how this works internally.

I noticed that when having a window spread across two screens before closing, it will get restored only on the left-most screen. So maybe the restoring process works like this: First restore window size (which will always happen on the left-most screen) and after that restore position (moving the window to the correct position. The problem with this is that restoring the window size before setting the correct position might fail, although I am not exactly sure why. I first thought maybe the resolution of the screen where the window size is attempted to restore is too low but that is not true for all my tests. Also one would need to explain the "fall back" to the old resolution set before, which seems to be stored somewhere.
Comment 22 Claudius Ellsel 2021-01-25 16:25:53 UTC
Still happens with the current Plasma Beta.
Comment 23 Claudius Ellsel 2021-01-25 16:55:48 UTC
*** Bug 427808 has been marked as a duplicate of this bug. ***
Comment 24 Claudius Ellsel 2021-01-25 16:59:41 UTC
Adding some kwin people to CC as well, maybe they have a clue what is going on here.
Comment 25 Shawn 2021-01-28 14:20:03 UTC
I have a dual monitor setup with both resolutions at 2560x14440.  I can't do any of the coding stuff that you guys do, but if there is something I can test to help, let me know.  I say this because most of the comments I see are from ppl that have a laptop + some other screen, possibly with different resolutions.
Comment 26 Claudius Ellsel 2021-01-28 17:29:33 UTC
(In reply to Shawn from comment #25)
> I have a dual monitor setup with both resolutions at 2560x14440.  I can't do
> any of the coding stuff that you guys do, but if there is something I can
> test to help, let me know.  I say this because most of the comments I see
> are from ppl that have a laptop + some other screen, possibly with different
> resolutions.

A screenshot of your screen setup (and arrangement) from the systemsettings might be interesting.
Comment 27 Shawn 2021-01-28 18:53:45 UTC
(In reply to Claudius Ellsel from comment #26)
> (In reply to Shawn from comment #25)
> > I have a dual monitor setup with both resolutions at 2560x14440.  I can't do
> > any of the coding stuff that you guys do, but if there is something I can
> > test to help, let me know.  I say this because most of the comments I see
> > are from ppl that have a laptop + some other screen, possibly with different
> > resolutions.
> 
> A screenshot of your screen setup (and arrangement) from the systemsettings
> might be interesting.

Okay.  Probably doesn't matter, but I have two taskbars.  One on each screen showing only the applications that are on that screen.  

Also, the add attachment feature I think would make the picture unreadable if I tried to scale it down that much, so I used an external link.  Never done this before, so hopefully okay. =)

[url=https://postimg.cc/hQrhShz8][img]https://i.postimg.cc/hQrhShz8/desktop-screenshot.png[/img][/url]
Comment 28 Shawn 2021-01-28 18:55:00 UTC
err, let me try again I guess. Sorry: https://i.postimg.cc/t706Nx9c/desktop-screenshot.png
Comment 29 evea 2021-01-28 19:01:24 UTC
Is this reproducible by a dev yet? It seems pretty straightforward to me? Use the right monitor as primary, most applications will start on the left screen and window positions and sizes will not be remembered on the Primary screen.

Also, this is not a phenomenon which happened with the last update (which added the feature of remembering those settings), but has always been the case, people just now expected it to work.

This is by far the biggest and most annoying issue I have with KDE.
Comment 30 Nate Graham 2021-01-31 16:52:35 UTC
*** Bug 431620 has been marked as a duplicate of this bug. ***
Comment 31 Nate Graham 2021-01-31 16:52:52 UTC
*** Bug 431621 has been marked as a duplicate of this bug. ***
Comment 32 Ricardo Steijn 2021-02-24 16:57:34 UTC
Same issue confirmed on my multi monitor setup.

I'm using 3840 x 2160 (150%) [LEFT] and 3440x1440 (100%) [RIGHT]

Video here https://youtu.be/GDf5ouFYcP4

I can provide specs, sysinfo and logs if necessary.
Comment 33 Nate Graham 2021-03-10 22:53:13 UTC
*** Bug 418470 has been marked as a duplicate of this bug. ***
Comment 34 Nate Graham 2021-03-10 22:53:55 UTC
*** Bug 378896 has been marked as a duplicate of this bug. ***
Comment 35 Nate Graham 2021-03-31 16:02:00 UTC
*** Bug 434970 has been marked as a duplicate of this bug. ***
Comment 36 Ismael Asensio 2021-04-04 11:07:30 UTC
Still reproducible on git master.

The problem is that KXMLGui always reads the size to restore from the config associated to the first screen, even when the window is placed on the second one. Then it saves the new size correctly, but to the config of the second screen, which is not read again.

Moving the report to kxmlgui, as the issue can be found probably there

Adding some simple debug lines and opening dolphin:
```
restoreWindowSize()  screen: "HDMI-A-1" QRect(0,0 1680x1050) sizeToRestore:  QSize(950, 480)
saveWindowSize()  screen: "HDMI-A-1" QRect(0,0 1680x1050) sizeToSave:  QSize(950, 480)
saveWindowSize()  screen: "eDP-1" QRect(0,1050 1920x1080) sizeToSave:  QSize(950, 480)
saveWindowSize()  screen: "eDP-1" QRect(0,1050 1920x1080) sizeToSave:  QSize(950, 480)
```
closing dolphin:
```
saveWindowSize()  screen: "eDP-1" QRect(0,1050 1920x1080) sizeToSave:  QSize(1072, 480)
saveWindowSize()  screen: "eDP-1" QRect(0,1050 1920x1080) sizeToSave:  QSize(1072, 480) 
```
Comment 37 Nate Graham 2021-04-05 00:36:05 UTC
*** Bug 435357 has been marked as a duplicate of this bug. ***
Comment 38 Armin 2021-05-07 02:48:55 UTC
I experience the same issue on my Fedora 34 laptop. 

I typically use a large external screen and disable the laptop screen, so technically only one screen active. However, I also tested this just with my laptop screen active (i.e. unplugged the external screen entirely) and I have the same issue.

No matter which screen arrangement I use, KDE/Plasma does not remember the window location. Also, all windows will be moved to the first virtual desktop after a reboot even if they were distributed over the 8 virtual desktops I typically use to compartmentalise my work.

Given the large number of duplicate bugs which more or less report the same issue, combined with the fact that I can reproduce this in a single and multi-screen setup, it seems there is something fundamentally broken in the logic that decides how to arrange the windows and this is not necessarily related to the number of physical screens.

Also, all applications are affected by this, KDE or others such as Google Chrome or XUL-based applications.

I only tested this properly on X11, wayland is not yet usable in a production environment anyway due to the lareg number of outstanding showstoppers issues.


SOFTWARE/OS VERSIONS
 OS: Fedora 
 Kernel: x86_64 Linux 5.11.17-300.fc34.x86_64
 DE: KDE 5.80.0 / Plasma 5.21.4
 WM: KWin
 CPU: Intel Core i7-7600U
 GPU: Mesa Intel(R) HD Graphics 620
Comment 39 hexer504 2021-05-17 08:23:52 UTC
I'm having the following issues as well when the default monitor is on the right and the secondary on the left:

- When right-clicking on a desktop icon the context menu opens some pixels on the left (even going the in the other monitor).
- The windows position/size/monitor is not remembered properly in some applications (like Dolphin).

SOFTWARE/OS VERSIONS
Operating System: Arch Linux
KDE Plasma Version: 5.21.5
KDE Frameworks Version: 5.82.0
Qt Version: 5.15.2
Kernel Version: 5.12.3-arch1-1
OS Type: 64-bit
Graphics Platform: X11
Processors: 20 × Intel® Core™ i9-10850K CPU @ 3.60GHz
Memory: 62.7 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 2060 SUPER/PCIe/SSE2
Comment 40 friedrich.schriewer 2021-07-19 01:53:08 UTC
Could it possibly be that there is an issue with the screen counting?

If you select to move a window to another screen the screens will be labeled Screen1 and Screen2 while Screen1 will always be the primary screen as can be seen here
https://drive.google.com/file/d/1w8UEU8rhTzjbMPp95lP5dxtTRVE2Y4WJ/view
(Also apparently you can't take screenshots while in a menu)

When you look at the way screens are displayed in the window settings, you will see that they start from 0 and count upwards. So in that case Screen0 is the primary screen.
https://drive.google.com/file/d/1MFi2Or8OsAsla0bn9UykVbgIibEgDWDN/view

Now if you force the screen to appear on Screen0 in the window settings, the window will appear on the primary screen. If you force Screen1 the window will appear on the secondary screen. So in my theory the window's last screen position will be saved as Screen1 mentioned in the first paragraph. But when loading the window, the window will be placed on Screen1 mentioned in this paragraph, so the secondary screen.

                          Secondary | Primary
saving window's screen        2     |    1
loading win's   screen        1     |    0
Comment 41 Nate Graham 2021-07-23 21:19:29 UTC
*** Bug 439366 has been marked as a duplicate of this bug. ***
Comment 42 friedrich.schriewer 2021-07-23 21:38:29 UTC
This fixed the issue for me.

Go to Settings > Window Management > Window Behaviour > Advanced

Uncheck Allow apps to remember the positions of their own windows, if they support it


Go to Settings > Window Management > Window Rules > Add New...

Set the Window Class to Unimportant

Under Window types uncheck everything except for Normal Window

Click on Add Property... search for Position and change Apply Initially to Remember.

Click on Add Property... search for Screen and change Apply Initially to Remember.

Set the value to 0.

This works for me, now every window I've never opened before will open on my primary screen and will remember it's position when I close it.
Comment 43 Armin 2021-07-24 02:47:53 UTC
(In reply to friedrich.schriewer from comment #42)
> This fixed the issue for me.

Unfortunately, this does not really fix it for me. So, while introducing rules to manipulate the window placement indeed forces the windows to obey these rules, it seems to only "remember" one position per application where it should remember the position of every window.

For example, if I open two documents in okular and arrange them on my screen say side by side, kwin will only remember the position of one of them and apply it to the other one as well. This applies to window positioning as well as placement on virtual desktops (the latter being a real pain in the neck for me).

At least that's the behaviour on my system running the latest KDE Plasma version:
 OS: Fedora 34
 Kernel: x86_64 Linux 5.13.4-200.fc34.x86_64
 DE: KDE 5.83.0 / Plasma 5.22.3
 WM: KWin
 CPU: Intel Core i7-7600U
 GPU: Mesa Intel(R) HD Graphics 620

Which KDE/ Plasma version are you on?
Comment 44 friedrich.schriewer 2021-07-24 03:37:43 UTC
Yes after some more testing I had the same results you described.

I've now added rules for every application, but something like this is not very enjoyable or time efficient.

Maybe - until a proper solution is found - we can use KWin Scripts to automate that process by adding a new rule  with the described settings for every application each time a new window is opened, if there is not already one available. Unfortunately I was not yet able to get my head around how this system works.

 OS: Manjaro
 Kernel: Linux 5.10.52-1
 DE: KDE 5.83.0 / Plasma 5.22.3
 WM: KWin
 CPU: AMD Ryzen 5 Six core
 GPU: Nvidia GeForce GTX 1060 6GB
Comment 45 Ismael Asensio 2021-08-23 19:51:24 UTC
For what I could investigate, the problem here is not on save (it saves the right size to the right monitor), but on loading.

When the app opens, the wrong window is passed to the size loading method, so it loads the size for that window.

Then, the screen associated to the window is changed, a signal emitted (this is a guess) and that previous size is saved to the other monitor, overriding the previous setting.

I think the issue is that we try to load the size setting too early, before the compositor has placed the window in the final screen.
Comment 46 Nate Graham 2021-09-16 17:48:39 UTC
*** Bug 442467 has been marked as a duplicate of this bug. ***
Comment 47 Nate Graham 2021-09-16 17:48:55 UTC
*** Bug 387736 has been marked as a duplicate of this bug. ***
Comment 48 Nate Graham 2021-09-16 17:49:56 UTC
from duplicate Bug 387736:

Inside KWindowConfig::restoreWindowSize
const QRect desk = window->screen()->geometry();
always returns resolution of the most left screen (regardless whether it is primary and regardless of where the window actually appears).

This seems to be the same bug as reported here: https://bugreports.qt.io/browse/QTBUG-50788

This have a nasty effect that when you open kf5 application it always has [a size it had last time when it was closed on most left screen].


Even if it is found out that this is a qt-bug workaround is probably possible, because the virtually same code inside KWindowConfig::saveWindowSize returns correct screen.
Comment 49 Lo 2021-10-20 08:16:50 UTC
It seems like the issue is only present when windows are opened in a maximized state. Then they will always open on the left-most screen. 

Part of the bug is that once the window was maximized and then closed, any custom window rule regarding placement is ignored.

# Workaround

Window maximization seems to be flag, that when applied, triggers the bug. Window rules can take advantage of this by forcing the flag to false to then allow placement.

 - Under "Settings > Window Management > Window Rules" either add a new rule or modify an existing one. 
 - Move your window to where you want it to be when you open it
 - "Detect window attributes" (translated from French)
 - Select "Position", "Size", "Horizontally maximized" and "Vertically maximized"
 - Set "Horizontally maximized" and "Vertically maximized" to "No" (or false)

Hopefully, next time you open your window, it will look maximized (but the flag will be false), and it will be on the right screen.

Hopefully this also helps the devs with debugging. Maybe the "maximized" flag/state is entering a different execution branch.
Comment 50 Stefan Radermacher 2021-10-20 10:10:21 UTC
(In reply to Lo from comment #49)

I can confirm this exact behavior on my system. I think it started in early October, after I updated to the Plasma 5.23 beta.

The workaround helps, but I hope this gets fixed soon.
Comment 51 popov895 2021-12-11 20:06:07 UTC
*** Bug 443251 has been marked as a duplicate of this bug. ***
Comment 52 Deckweiss75 2021-12-20 14:36:33 UTC
https://youtu.be/cicGZXrWBQU

Is this the same bug or a different one?

After a fresh boot, applications that I drag from my primary monitor to my secondary one, keep assuming horizontal maximize.
Comment 53 myndstream 2022-01-01 11:16:24 UTC
Just a short note: this has been occurring on my Debian11/KDE system for a long time with the VeraCrypt GUI. It always opens on the left nonprimary screen even if it's been moved to the right screen and then closed. The window is *not* maximized. If I move it to the primary screen and then click "mount", the new window that's getting opened still opens on the left screen.
Comment 54 smtea923 2022-01-18 05:26:56 UTC
Also still getting this, things seem to remember the correct monitor at least, but size and position is reset for most applications on launch, also using a two monitor setup with my right monitor being the primary, and the left as a secondary

As soon as I disable my left most monitor in KDE's display configuration (keeping only my original primary as my single monitor) then applications remember their size and position correctly, re-enabling my left-side secondary monitor again immediately causes these programs to *reset* to how they were opening before, completely forgetting any of the position or size it was using with just my primary monitor active

Operating System: Arch Linux
KDE Plasma Version: 5.23.5
KDE Frameworks Version: 5.90.0
Qt Version: 5.15.2
Kernel Version: 5.16.1-237-tkg-pds (64-bit)
Graphics Platform: X11
Processors: 12 × AMD Ryzen 5 3600 6-Core Processor
Memory: 15.6 GiB of RAM
Graphics Processor: AMD Radeon RX 570 Series
Comment 55 evea 2022-03-09 04:37:02 UTC
This bug report should not be limited to X11, the same exact thing occurs in Wayland.
Comment 56 Gentleman Otter 2022-03-27 00:29:33 UTC
I have the same issue. For me I notice it on Spectacle on my left screen. It saves the position but not the size. It's always too small. I'm running 3 2560x1440 monitors on Kubuntu if anyone wants me to test anything.
Comment 57 giggi1999 2022-04-19 14:23:52 UTC
Same problem here on ArchLinux

I've a laptop with two external monitors (in total three monitor).
normally KDE starts two desktops on one of the two external monitor, so that the primary display of the laptop is blank. 

If right-click: "configure desktop" it opens two dialog windows on one of the two eternal monitors.
While on the laptop the right-click menu does not appear.

It also starts two overlapped panels on the display of the laptop.

X11 with NVidia driver.
Comment 58 giggi1999 2022-04-21 06:44:59 UTC
(In reply to giggi1999 from comment #57)
> Same problem here on ArchLinux
> 
> I've a laptop with two external monitors (in total three monitor).
> normally KDE starts two desktops on one of the two external monitor, so that
> the primary display of the laptop is blank. 
> 
> If right-click: "configure desktop" it opens two dialog windows on one of
> the two eternal monitors.
> While on the laptop the right-click menu does not appear.
> 
> It also starts two overlapped panels on the display of the laptop.
> 
> X11 with NVidia driver.

If I move the primary screen from the laptop to one of the external monitor the problem is switched. So that the blank screen is always on the primary display.
Comment 59 Pat 2022-04-24 13:31:17 UTC
Same problem with dual monitor setup (left vertical second screen) on Opensuse Tumbleweed - KDE Plasma 5.24.4 + Nvidia driver + x11
Comment 60 giggi1999 2022-04-28 06:02:54 UTC
This bug resolves itself if I open the "Configure Desktop" dialog from the right click, and start randomly editing the background image.
After a bit of "work around" (randomly editing background images) the problem resolves itself.
Comment 61 RealDude 2022-05-29 13:59:24 UTC
Same bad behavior on a freshly installed Kubuntu 22.04 with KDE Plasma 5.24.4
Comment 62 Bug Janitor Service 2022-06-28 14:58:49 UTC
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kconfig/-/merge_requests/129
Comment 63 Riccardo Robecchi 2022-08-17 20:42:06 UTC
*** Bug 457950 has been marked as a duplicate of this bug. ***
Comment 64 lands.wilmoth 2022-08-20 00:00:56 UTC
I am experiencing the same symptom with Konsole and Dolphin. Only if I open them on one of my four screens is the size and position remembered. Even if I then move them to another screen and close them, the original screen, size, and position is recalled the next time I open the program. That is, the last remembered screen, size, and position is not remembered.

Interestingly, I am not experiencing this symptom with Brave, Firefox, Mahjongg, Mines, or gThumb. Not sure what the difference is.

Also, I only noticed this symptom after I connected my 4th monitor last week (my video card supports up to four). Even if I set the one monitor that seems to be "the master" (i.e. only one remembering and enforcing last details) the primary monitor, nothing changes.

Window Behavior > Advanced > Window placement = Centered
Window Behavior > Advanced > Allow apps to remember the positions of their own windows, if they support it = Checked

From Info Center:
- Ubuntu 22.04
- KDE Plasma Version: 5.24.4
- KDE Frameworks Version: 5.92.0
- Qt Version: 5.15.3
- Kernel version: 5.15.0-46-generic (64-bit)
- Graphs Platform: X11
Comment 65 evea 2022-08-20 00:06:22 UTC
I do not understand why the title still mentions, and the bug is limited to X11. The exact same symptoms happen with Wayland.
Comment 66 lands.wilmoth 2022-08-20 16:04:42 UTC
Interestingly, most other windows, such as Visual Studio Code, Super Productivity, IntelliJ IDE, Android Studio, Virtual Machine Manager, do not exhibit the symptom. These all remember size and position without issue.
Comment 67 Armin 2022-08-20 16:24:19 UTC
(In reply to lands.wilmoth from comment #66)
> Interestingly, most other windows, such as Visual Studio Code, Super
> Productivity, IntelliJ IDE, Android Studio, Virtual Machine Manager, do not
> exhibit the symptom. These all remember size and position without issue.

I have a similar experience since I switched to Wayland when upgrading to Fedora 36. Applications still running on XWayland seem to actually remember their size and position, but all native Wayland applications, including all KDE applications, don't even get restored on restart.

Also, this behaviour is the same with or without an external screen. Thus, one could argue that this is not the right bug report anymore, but then again, the behaviour has changed throughout the years without any source code changes linked to this bug report. It kind of leaves the impression that there is currently no developer that is on top of these code paths.
Comment 68 Claudius Ellsel 2022-08-29 16:37:50 UTC
(In reply to evea from comment #65)
> I do not understand why the title still mentions, and the bug is limited to
> X11. The exact same symptoms happen with Wayland.

It isn't. The X11 part is just an addition of what is needed to trigger this bug on X11, as far as I see it.
Comment 69 Nate Graham 2022-09-16 13:59:59 UTC
Git commit 21e02655a78b5d241c35fd934f7665564420327c by Nate Graham, on behalf of Richard Bízik.
Committed on 16/09/2022 at 13:59.
Pushed by ngraham into branch 'master'.

Fix size and position restoration on multimonitor setups

Configuration was not being picked up due to window being
placed on a left most screen. Added configuration of latest screen on
which window was placed which is used to load a propper
configuration for that screen.
Related: bug 458963

M  +72   -34   src/gui/kwindowconfig.cpp
M  +16   -1    src/gui/kwindowconfig.h

https://invent.kde.org/frameworks/kconfig/commit/21e02655a78b5d241c35fd934f7665564420327c
Comment 70 Stefan Radermacher 2022-09-16 15:44:40 UTC
> https://invent.kde.org/frameworks/kconfig/commit/
> 21e02655a78b5d241c35fd934f7665564420327c

This patch helps with windows where they should open after they were closed. However, there is still another aspect of this bug. When I have windows open on the right-hand screen and the monitors go into sleep mode, once they wake again the positions and sizes of these windows are changed, everything is moved partly to the left, so that the windows straddle both monitors.

For information purposes, I have two monitors, my main monitor is at 3940×2160 and to the right, the second monitor is at 1920×1080 and to the left.
Comment 71 Nate Graham 2022-09-16 15:45:38 UTC
That's a different thing and that behavior comes from KWin. It should also have been fixed already in Plasma 5.26.
Comment 72 Stefan Radermacher 2022-09-16 22:37:39 UTC
(In reply to Nate Graham from comment #71)
> That's a different thing and that behavior comes from KWin. It should also
> have been fixed already in Plasma 5.26.

Is there a bug I can comment on? I just installed the Plasma 5.26 beta to check this, but this actually breaks my system completely. When the monitors wake up, now the right monitor gets no signal at all, and Plasma tries to paint both screens on the left monitor, which leaves the system unusable until I kill X.
Comment 73 evea 2022-09-18 21:30:39 UTC
(In reply to Nate Graham from comment #69)

Thank you so much to Richard Bízik and Nate. This is the biggest commit in the last years for me, the actual showstopper why I could not recommend KDE to some people.

Will this make it in the 5.26 release?
Comment 74 Nate Graham 2022-09-18 21:35:57 UTC
Awesome!

The fix is in Frameworks, so folks will get it next month--as long as they're using a distro that regularly ships Frameworks updates.
Comment 75 Claudius Ellsel 2022-09-19 13:23:01 UTC
Reopening for now as this is still not fixed for Wayland. Also see https://invent.kde.org/frameworks/kconfig/-/merge_requests/129#note_527114 for details.

Please let me know in case the Wayland problems should be treated in another report. Repurposing bugs that were for Wayland originally and then extended for X11 to be only about X11 probably can happen by accident, though is far from ideal, IMHO.
Comment 76 Viktor Jägersküpper 2022-09-19 13:32:31 UTC
(In reply to Nate Graham from comment #10)
> The feature to remember window sizes and positions using KXMLGui is not used
> on Wayland.
> 
> Remembering window positions on Wayland requires implementing Bug 15329.

There was some confusion here about Wayland vs X11, but I think this means bug 15329 is for Wayland. Nate, can you confirm?
Comment 77 Claudius Ellsel 2022-09-19 13:35:01 UTC
(In reply to Viktor Jägersküpper from comment #76)
> (In reply to Nate Graham from comment #10)
> > The feature to remember window sizes and positions using KXMLGui is not used
> > on Wayland.
> > 
> > Remembering window positions on Wayland requires implementing Bug 15329.
> 
> There was some confusion here about Wayland vs X11, but I think this means
> bug 15329 is for Wayland. Nate, can you confirm?

Also fine. But If you read my original comment here, I specifically said that it happened on Wayland for me and that I haven't tested on X11.
Comment 78 Nate Graham 2022-09-19 14:31:24 UTC
Unfortunately I got confused and duped a bunch of X11 bugs to this, and that issue has been fixed. Sorry for that. At this point it's confusing to re-open the original issue given that it was (unfortunately incorrectly) marked as the parent for 9 duplicate reports, so let's keep this one closed.

Regardless, apps don't do their own positioning on Wayland, so your original issue was purely a KWin problem. So for simplicity's sake, if you're still experiencing it with Plasma 5.26 (which made improvements here) please submit a bug report on KWin. Thanks!
Comment 79 Claudius Ellsel 2022-09-19 16:43:05 UTC
(In reply to Nate Graham from comment #78)
> Unfortunately I got confused and duped a bunch of X11 bugs to this, and that
> issue has been fixed. Sorry for that. At this point it's confusing to
> re-open the original issue given that it was (unfortunately incorrectly)
> marked as the parent for 9 duplicate reports, so let's keep this one closed.
> 
> Regardless, apps don't do their own positioning on Wayland, so your original
> issue was purely a KWin problem. So for simplicity's sake, if you're still
> experiencing it with Plasma 5.26 (which made improvements here) please
> submit a bug report on KWin. Thanks!

Works for me! As has asked before, it seems that https://bugs.kde.org/show_bug.cgi?id=15329 already might be about this exact problem?
Comment 80 Nate Graham 2022-09-19 17:17:05 UTC
Bug 15329 tracks having KWin remember individual window positions on screen on Wayland, yeah.

Closely re-reading your original bug report, it's possible that this is what's needed to fix it, but it's also possible that it was (is?) a KWin bug.

If in step 6, Gwenview opens on the wrong screen, but it happens to be the same screen your cursor is on, then Bug 15329 will be needed to fix it.

If in step 6, Gwenview opens on the wrong screen, but it's also a different screen from the one your cursor is on, then it's a bug in KWin.
Comment 81 Claudius Ellsel 2022-09-19 18:04:05 UTC
Alright! I'll have another look at it when I test again. Likely, it's not a bug in KWin, but not sure :)
Comment 82 David Rubio 2022-10-10 01:07:29 UTC
While this is Wayland-specific, in Wayland windows do not remember window *size* if there's a secondary monitor... only if the left-most display is not the primary one. This is on Plasma 5.26 (beta) with KDE Frameworks 5.99. Is there any bug tracking this? It's quite an ordeal to have to use my left monitor on the right if I want... usable window sizes, since at 1440p the default windows sizes are tiny.
Comment 83 Nate Graham 2022-10-11 16:28:01 UTC
Not to my knowledge; let's get a new one going. Can you make sure to write detailed steps to reproduce in it? Thanks!
Comment 84 David Rubio 2022-10-11 18:21:54 UTC
(In reply to Nate Graham from comment #83)
> Not to my knowledge; let's get a new one going. Can you make sure to write
> detailed steps to reproduce in it? Thanks!

I filed it on 460260. Let me know if you need anything more on that issue, please.
Comment 85 Nate Graham 2022-10-19 15:40:32 UTC
*** Bug 423191 has been marked as a duplicate of this bug. ***