Bug 360478

Thanks for the report

> plasmoids should not be automatically rearranged when applications
temporarily change the resolution (the user doesn't explicitly change it
in the display settings)

But we don't know that. All goes through various levels and roundtrips
to the display server, in the end Plasma receives only "screen resolution
changed". Plasma cannot know if that is a legitimate request or just
a temporary change.

I'll leave this open for others to comment, but I don't think this is (easily)
fixable.

(In reply to Martin Klapetek from comment #1)

I'm not sure what the best solution is either. I can only say as a user that the current behavior is problematic, and I think we need a way to prevent applications from accidentally breaking the desktop when changing the display resolution. I'm inclined toward remembering each widget's positioning per resolution though.

Example: Your screen is set to the standard resolution of say 1600 x 1200. You add a new plasmoid to the desktop, so its scale and position are stored under the 1600 x 1200 field. Now a game sets the display to 1024 x 768; If it's the first time this happens, we automatically reposition the plasmoid and store the new shape in the 1024 x 768 field... whereas if the field already exists, we simply move it to the existing shape for this resolution. If the user ever resizes or repositions a plasmoid, we drop all cached resolutions except for the current one.

I think that's actually quite sensible. Thanks.

Created attachment 98773 [details]
screenshot of 1920x1200 desktop after game changed resolution to 1280x960 and back

As you can see in the screenshot not only the widgets on the desktop are affected, krunner also opens at a wrong position: still at the top but assumingly in the middle of the temporary resolution (1280x960) not the former and current one (1920x1200).

The digital clock was at the most right on the desktop below the weather as was the disk widget. The analog clock is not affected, the position stayed the same. The weather is not a widget.

This issue also frustrates me.  In fact I just removed all widgets from the desktop as I am tired of fighting them.  

Solution:  Widgets should be anchored  from their closest screen edges as a percentage of the current screen resolution.  Auto resizing should also be handled as resolution ratio.  That way widget would gracefully resize and move to predictable locations as the screen changes resolution.

> MINOR?! Are you serious?

Fixed. The original reporter actually states that it is a major issue.

Certainly not a junior-job.

Yeah not sure why I marked it as minor. I think I considered it such because I could ultimately avoid the issue, by not running games in fullscreen before setting the resolution to the same as the desktop. This is a big problem still, as it does basically corrupt your desktop setup.

(I'm the person who reported the 'See also')

I'm no coder, and don't know the architecture of Plasma 5. 
Though I permit myself to make comparisons with Android, as well as Plasma 4, netbook, which was - for me - so far the best interface yet. Including on my 24" 1920x1200 monitor!

Unfortunately, it went away, and yet it had always behaved properly in these cases. It was close to Android by allowing icons in a predefined grid (actually more than one, depending on the location on screen), and shifting / wrapping in cases of smaller desktop resolution. 

I don't think that a 'hardcoded' geometry makes much sense. And if, it ought to be not absolute, but relative. With all-SVG it should be possible to re-map any icon map to a smaller map by scaling the former one down. As as second proposal to solve this, when the positions are relative to the screen edges.

373642 is why I mentioned Android. Before using Android, I had come to see the advantage of starting something - or opening a folder - with a single icon. Later I found this element on Android. While on Plasma 5 it is gone. 
Half the world uses Android, IOS, etc., and can arrange icons on a desktop. Icons that float whatever desktop size and rotation parameters are. And when the desktop overflows, it appends a second desktop to the right. 
It couldn't be wrong to implement well-known user interaction paradigms in KDE, could it? 
In no case should incrementing the Plasma number result in an interface of lower usability. That's my 10 cents on it.

(In reply to Christoph Feck from comment #9)
> > MINOR?! Are you serious?
> 
> Fixed. The original reporter actually states that it is a major issue.
> 
> Certainly not a junior-job.

Thanks, Christoph.

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

In comment #1, Martin Klapetek mentioned that we can't know if the resolution was changed by the user vs. some application.

Perhaps a way to solve this would be:
1. When a user adds or moves a widget, its position/dimensions are stored.
2. If a resolution change forces a widget to change position/dimensions, that change should happen dynamically but not alter the stored widget position. That way if a resolution is made smaller and then larger again, the widget's original positioning is not lost.

I think the above conditions would best follow the user's intent. No need to be storing per-resolution widget positions, which would make things more complicated than they need to be.

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

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

Just as a little remark, considering a different use case for Plasma:

All mentioned bug reports complain about the widgets been displaced after playing a game. Another annoying thing are projectors. When attaching the notebook to give a presentation, Plasma changes (hopefully... but that's another topic ;-) ) the resolution to the projector's, which can be as low as 1024x768.

As I started mis-using the Plasma desktop as a post-it-widget dumpground for topic based ToDos for now, they are resized and many even reduced to the small yellow icon. Restoring them all takes quite a while.

Created attachment 108892 [details]
Screen after laptop use

A picture is better than many words. Here a picture to explain my frustration.
I use my laptop once a day off the dock, and then I dock it back. The desktop will look inevitably like this attachment after docking, because the built-in screen doesn't provide the 1920x1200 resolution and re-positions everything to the 1440xsomething. When I attach an older projector, it gets worse. 

For a desktop project like KDE I consider this behaviour a good reason to look for a brown bag, sorry to say. Or, better, a speedy solution.

Proposal: We had on Plasma 4 an autowrap function in the netbook version, to break to another line with insufficient space. This could be in intermediate solution.
On the long term, similar to storing the different monitors and their resolution and evoking prior display settings at the moment of detecting an known display, this ought to happen here as well. Not bind to displays, but to resolution. So that I can have an icon set(ting) to be done only once per resolution of the primary display encountered.

(In reply to Uwe Dippel from comment #19)

My screen looks way worse after a resolution resize; You not only see the widgets moved, but crushed and piled up on top of each other in an indistinguishable mess, as I have too many of them to fit at such a small resolution. Something that happens whenever I first run an unconfigured video game, which for some reason chooses to both default to fullscreen as well as 640 x 480 resolution.

The only easy workaround is to keep a backup of ~/.config/plasma-org.kde.plasma.desktop-appletsrc which contains your desktop settings; Whenever the resolution breaks the widgets, just kill plasmashell overwrite that file with your backup and start Plasma back up again. This saved me of the tedious work of manually rearranging everything quite a few times.

Thanks, Mircea!

But then it only needs someone better with scripts than me, to devise a dirty workaround:

At starting plasma, check the prevailing screen resolution, and check a pool (folder) of existing config files. If a setting for this resolution exists, copy it as ~/.config/plasma-org.kde.plasma.desktop-appletsrc.

At/after closing plasma, copy the current .config/plasma-org.kde.plasma.desktop-appletsrc into that pool (folder), including the current resolution. Kind of plasma-org.kde.plasma.desktop-appletsrc_1600_900.

This is only dirty, since it won't accommodate any resolution changes *during* a session, but would help many of us to get a proper layout for their various resolutions. 

For your case: I wonder if it is possible to disable the widget changes *within* a session. Because then, when starting your desktop session, you obtain your preferred layout (widgets), while during the fullscreen game, these remain untouched. (Shouldn't be a problem, since you have a full-screen game session.) So that when you close the full-screen session, the widgets are where they had been earlier.

(In reply to Uwe Dippel from comment #21)

My proposed workaround should be pretty simple: Reposition the widgets as you do currently, but store their geometries per resolution rather than globally. That way, when you revert to a resolution or one higher than it, you use the last stored position for it.

Not sure if this is the best way to go, so if anyone has other ideas by all means let us know! This is just the easiest fix that came to mind.

Hopefully Wayland allows us what the AmigaOS had in 1985: The ability to create multiple "screens" for the same monitor, with different resolutions, so that games can use any resolution they want without affecting the desktop.

Anything else looks like a workaround.

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

Was able to reproduce this issue with Teewords game on non-native 1366x768 resolution

Plasma: 5.12.2
Apps: 17.12.2
Frameworks: 5.43.0
Qt: 5.10.1
Kernel: 4.14.25-1-MANJARO
OS: Netrunner Rolling
Video: Intel 4400
xf86-video-intel 1:2.99.917+812+g75795523-1
Screen: 1600x900

>Hopefully Wayland allows us what the AmigaOS had in 1985: The ability to create multiple "screens" for the same monitor, with different resolutions, so that games can use any resolution they want without affecting the desktop.

It will and should already for wayland fullscreen clients.

When they go true-fullscreen we render them directly, and that means there's no need to change the resolution of what we draw or the wl_output. If that doesn't change, plasma won't do anything.


>Reposition the widgets as you do currently, but store their geometries per resolution

Panels do that for their size. It gets /far/ more recurrent bug reports than this issue ever has. Imagine some virtualbox user resizes a window and all their stuff resets. It's all fixable, but before you know it you're at a full differential synchronisation algorithm...

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

Hello, I also have this issue and I have to resize and reposition 9 widgets.
We need to have several solutions for this.
One would be backup/restore of widgets configuration. This would help restoring after a reinstall.
Also, restoring after 3D windowless layer/application fullscreen should be known and should be able to restore the widgets layout. I see a way, resolution-related widgets configuration. I know it is a possibility to have a big config, as effect, also some things changed between resolutions changes, but should solve decently the majority of situations. It is possible to know when the widgets are resized by the user or by resolution change also.

It's gotten worse with kubuntu 18.04.
Why? It seems the starting screen is read earlier than with 16.04, and so whenever I boot, the items are repositioned. I start the laptop and later on (starting KDE) I switch to the high-res screen. Earlier, with 16.04, the behaviour was different, since I could reposition all icons across the high-res screen, and after startup, they were located as before. Now I'd have to reposition each time after reboot.

Related bug? https://bugs.kde.org/show_bug.cgi?id=354802

I'm having the same issue with Debian Stable with Plasma 5.8.6.

It's strange that it doesn't occur with Steam games but if I play a non-Steam games in fullscreen, like through WINE for example, my widgets always move to the top left of the screen when the resolution is changed, I always have to re-position them.

Has there been any updates on this?

I just tested this on the latest KDE Neon Developers Edition and it's still not working... Here are my specs:

KDE Plasma Version: 5.15.4
KDE Frameworks Version: 5.58.0
Qt Version: 5.12.0
Kernel Version: 4.13.0-45-generic

The way I tested this was the following:

1) I placed four folders on the bottom right corner of my desktop. My display resolution was 1920x1080.
2) I manually changed my resolution to 800x600.
3) The folders moved to the top left corner of the desktop. (this behaviour is ok I guess, since the folders would not appear on the desktop otherwise)
4) I manually changed my resolution back to 1920x1080.
5) The folders DID NOT move back to the bottom right corner of my desktop. (this right here is the bug as far as I'm concerned)

Now, I am going to try to give this bug some extra visibility by posting a new bounty. Here it is:

https://www.bountysource.com/issues/73566821-desktop-widgets-are-permanently-repositioned-when-fullscreen-games-lower-display-resolution

To release the bounty I will need to see this bug fixed in a KDE Neon Developers Edition installation. The fix will have to be able to address the 5-step scenario detailed above!

Happy hunting! :)

Thanks for the bounty! And for the very good description!

I have - I think - ranted enough on things like this. Though, acer11kubuntu, it is not that easy. It did work perfectly okay in Plasma4, since the placement of items was dealt with there totally different.
The problem with this and other regressive bugs isn't the developers. They were trying hard to adopt to different display geometries. The problem is more in the KDE core, and quality control. Anyone with a bit of insight would have noticed behaviours like this (and other quite obvious items) in the early development phases, much earlier than at coding. 
The project structure would need a complete revamp to get it back to function. Look at the undertaking with Plasma 4 and Plasma 5 to adopt to modern, varying, screen geometries and touchscreens. This has been worked on for 10 years, and now someone found out that the item 'right click on a touch screen' has simply been overlooked. 
And, yes, I have offered my contribution at times, though the project was always asking for coding abilities. Which already points at the weak point that seemingly the project lacks structural development well before the first line of code is written. And what we see here is a logical consequence: I do agree that in order to adopt to varying geometries, the rigid structure of item placement as in Plasma 4 by floating the items from the top left corner needed to be done away with. What is stored now is the last auto-placement according to the screen size. This renders the fuzzy clock really fuzzy: also with respect to placement (I did report that as well). Because depending on the time of day, the rectangle of that clock changes its size, making the fuzzy clock wandering all about the available screen estate, including changing the size considerably.

>It's strange that it doesn't occur with Steam games but if I play a non-Steam games in fullscreen

It occurs if a game alters the screen resolution. Old school games tended to.

This is a non-issue on wayland where we don't have to adjust the wl_output size.

Maybe it is possible to let the user define a default resolution for which the plasmoids' positions are being saved when resolution is switched?

IMHO the positions for the temporary resolutions are not that important, just those for the every-day-usage.

Janet, not that easy. Then some of your apps simply don't show up? Like Leave? I wouldn't think that made it much better. 
A bit further up we had already discussed a possible storage. So that the user indicates a default desktop size to which the items revert whenever possible. Though then quality control indicated that would just be a work-around, no solution. 

'Wayland' is a red herring, David. We have been discussing it for several years, I have a relatively recent convertible on which Wayland is a no-go. I don't think you want to suggest that I wait for my next round of updating my PCs in 2022, 2023 to have a fully usable desktop?
That would definitely very bad marketing, don't you think so, by saying 'yep, a reasonable, fully functional desktop cannot be achieved with KDE in 2019 if you don't have most recent hardware'. 
In the old days, our evangelism was to the opposite: 'you don't have to buy the most recent PC to run modern software'.

I don't think the user should have to be responsible for telling the OS the resolution to store the widget geometry when logic could be used to deduce this instead. Perhaps something like this:
1. The stored geometry for widgets is only updated when the user:
  a. Moves/resizes a widget manually.
  b. Shuts down/logs out the OS (thereby we assume that the user is happy with the current screen resolution)
2. If a screen resolution change is detected during a session, the widgets' positions are read from the stored values and if necessary repositioned dynamically to avoid being placed outside the boundary of the visible display, but these new positions will NOT be stored.

If the resolution change is desired by the user, the new widget position will be handled sufficiently by #1 above.

Thanks for the insight, Uwe, and to everyone else for the input and suggestions. Not being a programmer, I did suspect it might not be as easy as importing Plasma's methodology, but did not know for certain. However, I used to be a business analyst, and the use cases for this functionality should have been foreseeable and obvious. Sure, the OS is free, but it's still reasonable to expect a certain level of professionalism about it, and I regard this oversight to be very 'amateur hour' and quite disappointing. It forced me to switch to Unity (and I guess I'll soon have to switch to GNOME). Quelle domage!

I've made my little workaround for this:
https://github.com/Hakuhonoo/plasma-state

Thank for idea to @Mircea Kitsune
Hope it will help someone :)

Thanks for the submission @Andrii Arendariuk, this is a simple, elegant solution. Kudos!

I took the liberty to run a couple more tests with your code in terminal, and realised how easy it is to actually use your code to create multiple backup files, in order to preserve icon positions per resolution (if that's what we want - and we should).
For example, I used this command when I was in 1920x1080:
cp -f ~/.config/plasma-org.kde.plasma.desktop-appletsrc ~/plasma1920x1080.bak

Then I changed resolution to 800x600, and I rearranged some of the desktop icons to new places so that I would feel more comfortable while working in this resolution.
Then I used this command (while still in 800x600) to preserve the icon positions for this state as well: 
cp -f ~/.config/plasma-org.kde.plasma.desktop-appletsrc ~/plasma800x600.bak

Then I changed resolution back to 1920x1080 and run the command: 
konsole -e killall plasmashell && cp -f ~/plasma1920x1080.bak ~/.config/plasma-org.kde.plasma.desktop-appletsrc && plasmashell &

which sure enough restored all my icons in the appropriate places.

Just for the heck of it, I also run the command: 
konsole -e killall plasmashell && cp -f ~/plasma800x600.bak ~/.config/plasma-org.kde.plasma.desktop-appletsrc && plasmashell &

which just placed the icons in the "800x600" pattern while I was still in the 1920x1080 resolution. But that was just me playing at this point.

The only thing remaining is someone with programming experience to make the script run automatically when there is a resolution change. 
To function properly this script should get as parameters both the "old" and "new" resolution and then call "backup" for the "old" resolution and "restore" (if a relevant file for this resolution exists) for the "new" resolution.

Obviously I'm biased because I desperately want to see a resolution to this issue, but let's discuss:

What are the downsides to this solution exactly?

(In reply to funkybomber from comment #41)
> Thanks for the submission @Andrii Arendariuk, this is a simple, elegant
> solution. Kudos!
> 
> I took the liberty to run a couple more tests with your code in terminal,
> and realised how easy it is to actually use your code to create multiple
> backup files, in order to preserve icon positions per resolution (if that's
> what we want - and we should).
> For example, I used this command when I was in 1920x1080:
> cp -f ~/.config/plasma-org.kde.plasma.desktop-appletsrc ~/plasma1920x1080.bak
> 
> Then I changed resolution to 800x600, and I rearranged some of the desktop
> icons to new places so that I would feel more comfortable while working in
> this resolution.
> Then I used this command (while still in 800x600) to preserve the icon
> positions for this state as well: 
> cp -f ~/.config/plasma-org.kde.plasma.desktop-appletsrc ~/plasma800x600.bak
> 
> Then I changed resolution back to 1920x1080 and run the command: 
> konsole -e killall plasmashell && cp -f ~/plasma1920x1080.bak
> ~/.config/plasma-org.kde.plasma.desktop-appletsrc && plasmashell &
> 
> which sure enough restored all my icons in the appropriate places.
> 
> Just for the heck of it, I also run the command: 
> konsole -e killall plasmashell && cp -f ~/plasma800x600.bak
> ~/.config/plasma-org.kde.plasma.desktop-appletsrc && plasmashell &
> 
> which just placed the icons in the "800x600" pattern while I was still in
> the 1920x1080 resolution. But that was just me playing at this point.
> 
> The only thing remaining is someone with programming experience to make the
> script run automatically when there is a resolution change. 
> To function properly this script should get as parameters both the "old" and
> "new" resolution and then call "backup" for the "old" resolution and
> "restore" (if a relevant file for this resolution exists) for the "new"
> resolution.
> 
> Obviously I'm biased because I desperately want to see a resolution to this
> issue, but let's discuss:
> 
> What are the downsides to this solution exactly?

I spent several hours trying to make the resolution change idea work only to eventually give up (at least for now).

What I tested out was to simply detect a "resolution change" from within a .sh script. 

This can actually be done. However, the problem is that when a program or game changes the resolution (temporarily?), it does not seem to actually change the desktop resolution, even though it seems that way visually. 

I tested this with Diablo 2 in Wine. While the game is running, the reported resolution, when requested from a .sh script, will be unchanged. Hence, we can not easily detect this. However, we could probably parse the configuration file and do a simple search and replace whenever it is corrupted.

I also tried simply comparing the md5sums of the configuration and backup files, but this does not work very well at all. It seems like other things also change the configuration file, and those changes will be overwritten every time we restore from a backup automatically. Hence, a search and replace is probably best.

Okay, I found another command that helped me detect resolution changes. Now I got a working script to restore the relevant section in the configuration file automatically, without overwriting the entire file.

It has build in logging for debugging, and should also take a backup of your full file, before modifying it. I almost lost my file 1 time, since I was working on the script without making a backup first. Doh!

I could use some help getting the literal string replacement to work in bash, I had to do it in PHP, since escaping the relevant characters proved to be very difficult.

The scripts can be found here:

https://github.com/jacobkri/kde-containment-guard

Same issue here. Other reason.

If Plasma wakes up after the "Screen Energy Saving" was active the icons and widgets are rearranged. 

I have two monitors.
One monitor turns on faster than the other, resulting in a change in resolution. The same behaviour can be reproduced when the main monitor is turned off, so that the second monitor with a lower resolution becomes the default screen.

> I have two monitors.
> One monitor turns on faster than the other, resulting in a change in resolution.
> The same behaviour can be reproduced when the main monitor is turned off, so that the second monitor with a lower resolution becomes the default screen.

Same here, with 3 monitors and one TV. Two of them only go into standby (and are always recognized by Plasma) but if I turn off my main monitor Plasma registers that and shifts everything around. Now sometimes I would like to watch something on my TV and turn the monitors off... My widgets are always shifted around after that and it's quite annoying. Even just plugging in the TV shifts the widgets around a bit on the other screens.
The current stable Plasma version even shifts them around on login as SDDM only recognizes the one connected to my dedicated GPU which is just horrible (compiling Plasma myself in part because of that, at least that seems to be solved upstream).

Not only resolution changes btw. Another aspect of the problem is, for example, affecting users who have several GPUs (like iGPU, dGPU and eGPU) and switch between them. An easy and obvious example is Nvidia Otimus laptops: widget layout and wallpaper don't survive the switch from Intel to Nvidia, a user is forced to duplicate widgets for each mode.

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

Hello, not moving the widgets is not the solution, because, assuming the resolution changes to a smaller one, some widgets might end up outside the desktop, hence inaccessible. I've had this in a virtual machine already, so I have seen some widgets used in the "add  widgets" pane, where they were counted as used on the desktop, but unavailable, due to the fact they were on the right edge before the resize. This requires some compromise. In such case, Rainmeter (a Windows widgets system) moved them to the new edge that was closest to them, compared to the initial position. IMHO, some profile should be done per resolution/GPU/whatever is necessary, in order to restore them. Or at least for the supported resolutions of the system, when changes.

@Mihai Sorin Dobresc, This is why I propose the following solution:

1. When a user adds or moves a widget, its position/dimensions are stored.
2. Whenever the resolution changes (or is initially set on boot), Plasma should parse the stored widget positions and dynamically reposition any widgets that would be off screen. Note that the widget's stored position would *not* be changed.

This way, the user's desired widget position is preserved when the screen changes back to its native resolution. Only when the user manually sets the new widget position should that position be stored.

Yes, that seems reasonable to me.

How it's implemented on other DEs/Windows? And why this problem exists only here?

(In reply to Nick Stefanov from comment #53)
> How it's implemented on other DEs/Windows?
I don't know. Maybe they save positions on a per-resolution basis.

> And why this problem exists only here?
Because nobody implemented it yet. :)

Rather than fixed positions perhaps a relative position could be used

Nobody should start quarreling among each other here, I think.

I do understand the frustration; and yet would like to point out, again, that it is not actually a real bug. It is an ugly design flaw that can not remedied with some lines of code. It firstly needs a coherent concept on the behaviour of icons in case of resolution change. Since not everything is SVG, it is not feasible to simply scale things down proportionally. 
There is conceptually no wrapping of icons (like in Plasma 4 or W10). Plus, there is no anchoring of any widget (like my fuzzy clock which is continuously walking all over the place simply by modifying its size when time display changes).

We actually proposed some remedial concepts; and I wonder why 'the developers' respectively the designers of Plasma 5 do not take any responsibility for their oversight, and propose a coherent concept for behaviour with changing resolutions. 
Just storing and retrieving a setting for each of the possible resolutions is nothing more than a temporary workaround, since a new resolution ought not force the user to redefine screen layout.

(In reply to Uwe Dippel from comment #59)
> We actually proposed some remedial concepts; and I wonder why 'the
> developers' respectively the designers of Plasma 5 do not take any
> responsibility for their oversight, and propose a coherent concept for
> behaviour with changing resolutions. 
> Just storing and retrieving a setting for each of the possible resolutions
> is nothing more than a temporary workaround, since a new resolution ought
> not force the user to redefine screen layout.
The same reason any bug isn't fixed or feature isn't implemented: because the developers are spending their time fixing things deemed to be of higher urgency (for example, making clipboard functionality and pasting work on Wayland).

I'm starting to feel like a broken record here. It's understandable that folks are frustrated, but asking "why isn't this fixed yet?" won't make it happen faster. Instead, it will demoralize and de-motivate the developers who happen to be CCs on this bug report who don't have an extremely thick skin and make it *less* likely that they will want to work on it, not more. The more comments and arguing are in a bug report, the more demoralized the average person becomes when reading through it--this includes any developers who feel like fixing the issue.

So complaining in the bug report is not generally an effective approach. If you want to see the issue get resolved faster, the options that work include:
- Working on it yourself
- Finding a technically competent friend or colleague to work on it for you
- Writing a polite blog or social media post about it to draw attention to the issue and find someone to work on it
- Paying a developer to work on it

Can we look at how others done it? Every other DE actually :)

Ask your car manufacturer to exchange the petrol-powered motor with a battery-powered motor. They will tell you that you need a different design. The situation is similar with many "old" open bugs, such as bug 341143, bug 354802, and bug 356446. You cannot just "fix" the code, because it has implications in the complete stack.

Valso, While I might agree with your stand, I don't agree with attacking Nate. He's just a helpful person. FOSS is about everyone contributing whatever possible. Be it coding, helping users, reporting bugs or translating. 
It doesn't help to attack anyone personally. And it would be wrong. 

As I had written earlier (sorry for the 'spam'!), it looks more like a problem of the structure of the project. This is just one of them. 14 years ago someone decided (perfectly okay and in a visionary manner) to drop KDE3 in favour of tablet and touch support, and a wide variation of resolutions. 
This bug here is a 'result' of the latter. Last year, I had to find out that there is no support for right clicks on the touch screen. ('oh, wow, true, we don't have it') 
Even more funny, in my opinion. 

And, yes, I had offered to help with this project, in quality control. Then I was asked to furnish samples for my credentials in coding. I had had project management in mind, design, you name it. There was no interest in that; only 'coding, to rectify bugs'. 
If you consider THAT quality control, no wonder where this project is unfortunately heading. "If you don't know where you're going, any way will get you there."

Last night and now several hours today, I did some testing in both a virtual machine and on the real machine. Now I'm 90% sure the cause of bugs 354802 and 360478 is Wayland. I did several different scenarios on the real machine and NONE of these bugs appeared with the open source nouveau driver.
I don't have the necessary knowledge to remove wayland and make nvidia proprietary driver work with the already present X server.

It's not Wayland and it's not driver related. If you set a row with icons from top to bottom and change to a lower resolution, they will move to a new positions no matter the driver or X/Wayland. It's DE flaw.

There seems to be a lot of confusion here. This is *not* a bug in the code that needs to be fixed. This is *not* an accidental change of widget positions, it's *intentional*.
This bug report is a feature request, to return the widget positions to where they were before on resolution change and back.

It has nothing at all to do with Wayland or X11, basically nothing with the startup process either. 

I think s_chriscollins proposed solution sounds good. Looking at the code though I'm honestly lost at where to even start.

(In reply to Xaver from comment #70)
> It has nothing at all to do with Wayland or X11, basically nothing with the

Then how do you explain the fact that part of these 2 bugs I mentioned doesn't happen with the nouveau driver where wayland is not present?

If I had to guess where your problem comes from then I'd say the driver is doing mode changes on login (had that one for a while too, on my 5700 XT and multiple monitors) and then Plasma shifts the widgets around to make it fit on the resolution it gets.

Wayland is a display server protocol. Neither it nor the driver have anything to do with widget placement. That's all exclusively handled by Plasma.

It's not a matter of finding out *why* widgets move, we already know that. It's wanted behaviour to move the widgets on a resolution change.
Fixing this is a matter of finding a way to move them back afterwards / make the change be not permanent if not explicitly done by the user, and implement that of course.

Can we please limit this discussion into discussion only relevant into actually fixing this bug?

I have subscribed by email here since I am sometimes a bit annoyed by this bug (or current behavior) and I'm interested to see if/when some progress has been made. I bet many others have done the same for similar reasons, and are not happy to get many spam notifications about some opinionated meta-discussion about how FOSS development and bug trackers should work according to some people .

Also, if you do comment, please try to keep your tone at least constructive. Remember, you have probably paid nothing for this software, and the developers are not your slaves. It is up to their decision what bugs they prioritize, and where they put their limited resources. Even if you had paid something for the development, bug trackers are not meant for this kind of meta-discussion, but you should use according channels (which were assigned while you made your contribution, if there are any) to give  your opinions to guide the development.

Thank you for your understanding.

Ville Aakko, totally agree in principle.
My excuses for contributing anything considered spam in here. Could you help me finding the avenue, please, to discuss principal matters like a broken DE design (as implicitly confirmed by Christoph)?

You might not be interested to learn that some people have argued already several years ago against some conceptual changes from Plasma 4 to Plasma 5. Others (including myself) have filed other 'bug' reports on other less-well-thought-through features of Plasma 5.  

I think all of us want to get this ugly thing solved, like yourself, and are mostly keen to advance KDE. 
However - it seems it does need reiteration! - this (like some others) is NOT a bug! 
It is a design flaw frightfully well implemented in code. 

Maybe it would be most honest to set this one (and a number of others) to WON'T FIX for Plasma 5?

I arrived here after trying to center a Latte dock in the bottom pf my desktop, and it not staying centered whenever I switched from my laptop to an external monitor.

Could the problem be that widget positions are all offset from a single origin (top or bottom left, not sure). Would it solve some/most of these issues if you could anchor widgets relative to any of the 9 base positions: top-left, top-center, top-right, center-left, ..., bottom-right? That way, after a screen resolution change plasma could just recalculate the new absolute coordinates based on the new screen resolution?

So just a quick update here:

I discussed this today with the other Plasma devs at the virtual Plasma sprint and there was general agreement that this is a real problem and that the proposed solution (remembering sizes and positions on a per-resolution basis) makes sense. I can't provide a hard timeline or make any promises, but I'll be pushing for getting that implemented in the 5.20 timeframe.

And that is GREAT news!!! Thank you Nate and all other contributors!!!

(In reply to Nate Graham from comment #77)

Thank you very much for the good news. I know the Plasma developers are busy, and there has been pressure to fix this as well as many old issues some of which are waiting for years now. Hopefully a way can be found to address more of them... especially given the Coronavirus lockdowns, which may give people who had other jobs and are now at home more time to work on software development.

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

(In reply to Nate Graham from comment #77)
> So just a quick update here:
> 
> I discussed this today with the other Plasma devs at the virtual Plasma
> sprint and there was general agreement that this is a real problem and that
> the proposed solution (remembering sizes and positions on a per-resolution
> basis) makes sense. I can't provide a hard timeline or make any promises,
> but I'll be pushing for getting that implemented in the 5.20 timeframe.

You go guys. Is there an implementation discussion somewhere to be seen?

No, I don't think anyone has begun work on this yet.

(In reply to Nate Graham from comment #77)
> So just a quick update here:
> 
> I discussed this today with the other Plasma devs at the virtual Plasma
> sprint and there was general agreement that this is a real problem and that
> the proposed solution (remembering sizes and positions on a per-resolution
> basis) makes sense. I can't provide a hard timeline or make any promises,
> but I'll be pushing for getting that implemented in the 5.20 timeframe.

Given the aproaching 5.20 KDE release, is there any progress on this?

I wonder if this is fixed now? With the latest version of KDE / Plasma, after a game temporarily changed my resolution and rearranged my widgets, the widgets went back to their proper positions once I set the desktop resolution back.

Created attachment 131840 [details]
attachment-5083-0.html

It seems to be fixed for me. I get scrollbars on the Desktop now, but that
is much better IMO.

On Sun, Sep 20, 2020 at 3:35 PM Mircea Kitsune <bugzilla_noreply@kde.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=360478
>
> --- Comment #84 from Mircea Kitsune <sonichedgehog_hyperblast00@yahoo.com>
> ---
> I wonder if this is fixed now? With the latest version of KDE / Plasma,
> after a
> game temporarily changed my resolution and rearranged my widgets, the
> widgets
> went back to their proper positions once I set the desktop resolution back.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

That's funny, I'm not aware of anything specifically done to fix this. I guess some other change must have fixed it by accident. Since multiple people are reporting it as fixed now, let's close it. Huzzah! We can always re-open if it turns out to be actually still broken.

I can confirm! I started a game in 640x480 resolution and after I exit the game, the icons are on the same places as they shoud be! Thank you!!!

Qt 5.15.1? I suspect Plasma simply doesn't get informed of screen size changes...

This is issue is fixed on Kubuntu 20.04, Plasma 5.18.5.

(In reply to Christoph Feck from comment #88)
> Qt 5.15.1? I suspect Plasma simply doesn't get informed of screen size
> changes...
If so, that would be both hilarious and terribly sad. However it would help pinpoint where in Plasma it needs to be fixed lol

(In reply to Christoph Feck from comment #88)
> Qt 5.15.1? I suspect Plasma simply doesn't get informed of screen size
> changes...

Nope, I'm with Qt downgraded to Qt 5.15.0 and this bug is still fixed.

Unfortunately it's a partial fix. Sometimes it's working but not always. Now I started HoMM III in 800x600 resolution and my icons doesn't return where they have been. Again...

I can confirm - the bug isn't fixed. I don't know when it's working but it mostly not. Now I tried In Cold Blood and after I exit the game, my icons are again on different possition, arranged in the upper section of the screen. We hoped somebody will work on this for Plasma 5.20 but it seems will not happen. Is there any hope for 5.21? Nate, is there any need for another talk with the devs, may be they forgot about this important problem?

Yes, and no.

I used to report a kind of dup, 397655, where it was reported that my beloved fuzzy clock was walking all over the desktop; growing and shrinking. That is, with each change of display, it would change its geometry, and then, controlled by some yet unknown algorithm, blow up and get smaller, and therewith 'corrected' its self-presumed location and size. 

In a nutshell, since my update to 20.04, the fuzzy clock stands pretty much unaltered at its location since update day.

So I assume, we have at least two different effects being responsable for the plurality of observed, similar, problems with desktop geometry.

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

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

I was going to open a new bug issue, but entered in this thread and reading the last comments, I think this is the same problem that happens to me.

My problem doesn't happen when some game changes desktop resolution, but when moving my laptop from home when I connect a external 1980x1080 monitor (setup as the main display, with 2 plasmoids near one edge), to the office where I connect other 1980x1080 monitor.

The first time you attach a new display to the laptop, it's set as a second display, remaining the laptop as the main one. At this moment, I set up again the 1080 monitor as the main one, in a setup similar to the one I use at home. Reorder my plasmoids and everything is fine.

The next trips from office to home and viceversa, it occurs that sometimes, when attaching the laptop to the same external monitor, I will expect to find the last correct setup, but instead, one of the plasmoids that is usually placed in the edge of external monitor, is not visible, other times is visible but placed in other position of the monitor, sometimes with width and height changed. Other times  this not happens at all and everything is correct on monitor changes, so don't know how to add more info. Is there a file that can be inspected to see the current/previous setups of the plasmoids?

This issue is not critical, but a little bit annoying, so a fix would be greatly appreciated.

Thanks

@Alex: It sounds like a dupe, but one can't be sure because of the 'sometimes' in the description. Also, the 'not visible' has never happened to me throughout the years of suffering. Icons were ALWAYS visible here, though coherently re-placed on the screen whenever a REDUCTION of resolution was encountered. INCREASING the screen resolution would result in the icons re-appearing in their respective most recent positions on said screen of lower resolution, ie the upper left corner. 

(Though slightly OT here, to all: It seems we have no file recording a specific file for desktop layout? I am asking because a few days ago my kubuntu 20.04 Desktop - for yet unknown reason - had disappeared at normal logout-login; reverting with a basic screen with three icons in the upper left corner, and the standard login background image with the split diagonale. If we had this file, one could at least save some layout, and reinstate it later; either at a situation like described in the bug, or one like I encountered.)

Exactly - I migrated over 300 Windows users to Linux but everywhere I have to install other DE for I'm sure at least 80% of them are typical Windows users - they put everything on the desktop. You can imagine what a mess it will be with KDE and what will be the disappointment.(In reply to Teunizz from comment #102)
> I agree. I love KDE but I don't dare to advertize it to non-KDE users
> because this bug makes KDE look like a joke.

Exactly - I migrated over 300 Windows users to Linux but everywhere I have to install other DE for I'm sure at least 80% of them are typical Windows users - they put everything on the desktop. You can imagine what a mess it will be with KDE and what will be the disappointment.

(In reply to Uwe Dippel from comment #103)
> @Alex: It sounds like a dupe, but one can't be sure because of the
> 'sometimes' in the description. Also, the 'not visible' has never happened
> to me throughout the years of suffering. Icons were ALWAYS visible here,
> though coherently re-placed on the screen whenever a REDUCTION of resolution
> was encountered. INCREASING the screen resolution would result in the icons
> re-appearing in their respective most recent positions on said screen of
> lower resolution, ie the upper left corner. 
> 
> (Though slightly OT here, to all: It seems we have no file recording a
> specific file for desktop layout? I am asking because a few days ago my
> kubuntu 20.04 Desktop - for yet unknown reason - had disappeared at normal
> logout-login; reverting with a basic screen with three icons in the upper
> left corner, and the standard login background image with the split
> diagonale. If we had this file, one could at least save some layout, and
> reinstate it later; either at a situation like described in the bug, or one
> like I encountered.)

May be you're looking for ~/.config/plasma-org.kde.plasma.desktop-appletsrc

Changing from 2K laptop monitor to 4K external monitor changes dramatically the icon disposition, I use Debian + KDE professionally and this bug forces me to use only the external monitor. Hope the developers will undertake some action. Many will be thankful.
All the best

Operating System: Debian GNU/Linux 10
KDE Plasma Version: 5.14.5
Qt Version: 5.11.3
KDE Frameworks Version: 5.54.0
Kernel Version: 4.19.0-12-amd64
OS Type: 64-bit
Processors: 12 × Intel® Core™ i7-9750H CPU @ 2.60GHz
Memory: 31,3 GiB of RAM

Please keep in mind that with each needless reply you're sending an email to 43 people. No amount of words in all caps will help you nor are they needed.

The Plasma devs care and already acknowledged this bug is a real problem and will provide a fix at some point as per comment 77.

Please keep new comments in this bug relevant to the actual bug. Thank you.

Created attachment 134203 [details]
Desktop

When connected to another screen with the same resolution even after setting the proper resolution in nvidia and kde settings ...

Created attachment 134204 [details]
Huge window headers

One bad thing that happened recently is when connecting to another screen the note widgets got so big that they disappeared and I lost the content I had saved in them. 

KDE Plasma Version: 5.20.4
KDE Frameworks Version: 5.77.0
Qt Version: 5.15.2

(In reply to farid from comment #116)
> One bad thing that happened recently is when connecting to another screen
> the note widgets got so big that they disappeared and I lost the content I
> had saved in them. 
> 
> KDE Plasma Version: 5.20.4
> KDE Frameworks Version: 5.77.0
> Qt Version: 5.15.2

There's a chance that content is still in your home dir configs, but just not used.

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

Git commit 156509b785b6b4312d984841f9ba6375687389d3 by Marco Martin.
Committed on 20/04/2021 at 09:41.
Pushed by mart into branch 'master'.

don't make config key change and size change conflict

Use a single timer instead of two and use flags for events that can
lead to a relayout. the flags at the moment are size change and config
key for serialization change.

if they happen in the same moment (for instance when the serialization
config key is dependent from the size) if the new key already is saved
consider it correct and don't try to keep the distance to screen edges
from the old layout, ruining the saved one

M  +58   -32   components/containmentlayoutmanager/appletslayout.cpp
M  +22   -2    components/containmentlayoutmanager/appletslayout.h

https://invent.kde.org/plasma/plasma-workspace/commit/156509b785b6b4312d984841f9ba6375687389d3

Git commit 1390b55188e032336a9e92fb74bd55260493f1eb by Marco Martin.
Committed on 20/04/2021 at 09:43.
Pushed by mart into branch 'master'.

Save layouts per-resolution

save a different applet layout per resolution
having a completely different layout makes much easier to have the
position of widgets not get destroyed every time resolution is changed,
like connecting external monitors or playing a game.

M  +3    -1    containments/desktop/package/contents/ui/main.qml

https://invent.kde.org/plasma/plasma-desktop/commit/1390b55188e032336a9e92fb74bd55260493f1eb

@Marco Martin
Thank you very much!!!
I can't wait to try the patches! Any idea when they will be merged?

They already were. :) The fix will be released in Plasma 5.22.

The bug report is still open because only widget position has been done so far; we still need to implement the same fix for Folder View so that desktop icon positioning is per-resolution too.

Oh, I didn't realized that. Thanks :)

Unfortunately I'm using Folder View so I hope for a patch soon :)

As you can see, there is hope for the patient! :)

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

I was hoping for this issue to be fixed with 5.22. Apparently a month later, the fix was reverted with a new commit. I thought i can finally be able to use sticky notes in my plasma desktop. 
Whoops!

The reversion was reverted after the bug it caused was fixed. However we know there are still remaining issues which is why this bug report is still open.

There are many issues remaining in this regard...

It is working  correctly in wayland session.I did not try running a lower resolution game but Widgets seems to hold it position in external monitor. Wayland sessions seems to be usable baring occasional freezes. Probably I will switch over to wayland session for a couple of days and see how it goes. 

Bug Kudos to KDE team for improved wayland support.
Thanks

Widgets are fixed hence not related to Wayland.

I'm looking into how to implement this for Folder View according to how https://invent.kde.org/plasma/plasma-desktop/-/commit/1390b55188e032336a9e92fb74bd55260493f1eb did it for applet positioning but it's not so easy to manipulate the config key ("positions") to add the screen resolution because it's hardcoded in the main.xml file. And the name is used in aliases and function calls that makes it not simple to just conditionally change.

I think someone more experienced than me will have to finish this up.

It's been reported for more than 5 years, and I do appreciate that it simply can't be solved, because it is not a bug. It is a serious design flaw after a breakdown of structured development within KDE (I won't go into details).
Anyway, the only feasible way for the current design is to work around it, like what Nate Graham stated, and tried to do. 

My personal workaround, with a 'sigh' and less than satisfactory is the installation of PlasmaConfigSaver, and store all the layouts that I use. And then writing back the one that I need, but is messed up by the most recent resolution change. 
Maybe, just maybe, it is possible to write a wrapper around this software, which calls it up at a detection of change of resolution. And then, reading the actual resolution, automatically load a saved config file, e.g. purposely named after that resolution.

Do you mean Plasma Customization Saver?

https://store.kde.org/p/1298955/

I can't find PlasmaConfigSaver.

Sorry, Nick, yeah, that's the one I meant. I called the icon with that other name. Sorry again.

As I think I've mentioned before, would it be possible to save the positions of widgets as a percentage, or ratio of the screen, rather than the pixels themselves, so when the resolution changes, things stay in the same place - it certainly would be better than having things go of the screen

And this bug was originally reported back in 2015 (https://bugs.kde.org/show_bug.cgi?id=356377)

Not really. It doesn't work all too well to mix the concept of SVG and pixel-oriented items. The icons wouldn't be aware of closer localities and overlap or being shifted around in an unforeseeable manner. 
More than 15 years ago, at KDE3 we were aware that different screens would be arriving, like large monitors, in landscape, and small portable ones, eventually in portrait. And the intention was, to allow for seamless switching. I had a number of discussions offline on this topic and how to solve it. Plasma 4 offered a crude, but working method: screen regions and then wrapping around. 
Seemingly, this problem was removed off the focus. Desktop layout must be an independent task, resolution and orientation aware, and scale according to resolution (some mobiles have huge dpi values) and physical diagonale.

This is not correct for switching between Plasma Styles either. Having different parameters between various parts of the items, like borders and text sizes, the widgets shuffle pretty much and they don't size correctly at setting back to the initial Plasma Style. My take would still be to keep widgets sizes in pixels and set them back just as the user resizes them by hand.

(In reply to Mike Lothian from comment #145)
> As I think I've mentioned before, would it be possible to save the positions
> of widgets as a percentage, or ratio of the screen, rather than the pixels
> themselves, so when the resolution changes, things stay in the same place -
> it certainly would be better than having things go of the screen
> 
> And this bug was originally reported back in 2015
> (https://bugs.kde.org/show_bug.cgi?id=356377)

This is the only solution that makes sense. Widget position and size should be relative (from 0 to 1 or 0% to 100%). 

The only problem I can see is that a change in resolution can break the size of the widgets. 

Still, once the usual resolution is set back, the widgets should all go back where they should.

Given that this seems to be a difficult issue to tackle, how about a workaround for the time being - like `Lock Widgets` ?

We used to have this, though I think it was mostly to prevent the user from accidentally moving things.. how about one that meant also "Do not let me move widgets, nor update them automatically" -- then you can `Right click desktop` -> `Lock Widgets` to toggle it.

A real solution would obviously be preferable, but this seems to me like a much easier to implement workaround so things don't get moved when doing things like rebooting / restarting plasma.

If only it was so easy. Locking to what? So your proposal is a recursion to the actual problem. If you have a desktop of 1920x1080 and switch to a basic VGA of let's say 800x600, what happens with the icons outside of that upper left quarter? Out of sight. 
I gladly concede that I haven't even looked at the code, if this is possible after all for an application to have its icons in nirwana. 

May I draw your attention to #141 / #142. Here the Plasma Customization Saver is a feasible workaround that at least you don't lose all your settings, and can even redraw the desktop.

> Locking to what?

Lock to the sizes and positions at the time of locking, and not updating automatically.

> what happens with the icons outside of that upper left quarter?

I was thinking if this was part of the desktop's right-click menu, and you *wanted* it to update because for example you changed a screen, you'd be able to easily do `Right click desktop` -> `Lock Widgets` to toggle them to unlocked, at which point it could automatically resize/rearrange things as needed.

> May I draw your attention to #141 / #142. Here the Plasma Customization Saver is a feasible workaround that at least you don't lose all your settings, and can even redraw the desktop.

This is nice, though as you said it is also frustrating that you have to do it manually - which can be quite annoying if you need to reboot a few times in a day or something. I also had an issue with it when I used it some time ago that it just didn't work at one point.

@Merritt

"A real solution would obviously be preferable, but this seems to me like a much easier to implement workaround so things don't get moved when doing things like rebooting / restarting plasma."

The sad thing is they move even without restart or resolution change. For example if I create a text file on the desktop, after certain time (or actions) somehow it's on another location. Total catastrophe of a DE...

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/608

Would be great if some of you all would test this MR (it's only for Folder View icons). Nick, Uwe?

Thanks Bharadwaj Raju!
I can compile Wine and apply patches to it but unfortunately I don't know how to use this.

(In reply to Nick Stefanov from comment #158)
> Thanks Bharadwaj Raju!
> I can compile Wine and apply patches to it but unfortunately I don't know
> how to use this.

In this case, you don't need to compile plasma-desktop. The easiest way to test this is going to be to patch the `config/main.xml` and `ui/FolderViewLayer.qml` files in `/usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents` with the changes in the MR. Then restart Plasmashell.

Alas, I was a developer some 15 years ago. Now I am retired, and don't feel able to do anything of this kind. 

Though I am sure that you can do this test - contrary to many other bugs - easily yourself: Just change the resolution, re-allocate your desktop icons, change the resolution back and see if you obtain the earlier desktop. 
In a nutshell: Switch between resolutions. 

Of course, I'd be most happy to see and comment on a video clip showing the behaviour(s) of the desktops across resolution changes. 

It would be a great step ahead if this worked, and probably would help the large majority of us users. 
The next step then would be to work on an algorithm to place the desktop items in a reasonable way on desktop with a new, not yet encountered resolution. 

Thanks a lot for your efforts, by the way!

(In reply to Uwe Dippel from comment #160)
> Though I am sure that you can do this test - contrary to many other bugs -
> easily yourself: Just change the resolution, re-allocate your desktop icons,
> change the resolution back and see if you obtain the earlier desktop. 
> In a nutshell: Switch between resolutions.

I know, I have tested it like that and so far the icons stay in their original positions when switching back. But I would just like to be sure that it works for others as well.

(In reply to Bharadwaj Raju from comment #162)
> (In reply to Uwe Dippel from comment #160)
> > Though I am sure that you can do this test - contrary to many other bugs -
> > easily yourself: Just change the resolution, re-allocate your desktop icons,
> > change the resolution back and see if you obtain the earlier desktop. 
> > In a nutshell: Switch between resolutions.
> 
> I know, I have tested it like that and so far the icons stay in their
> original positions when switching back. But I would just like to be sure
> that it works for others as well.

If this remembers positions on a per-resolution base, does that mean that, if I change the resolution, move the widgets around manually, and then change back to the original resolution, these new positions that I set manually would not apply?

(In reply to David from comment #164)
> If this remembers positions on a per-resolution base, does that mean that,
> if I change the resolution, move the widgets around manually, and then
> change back to the original resolution, these new positions that I set
> manually would not apply?

Yes, they would not apply.

(In reply to Bharadwaj Raju from comment #165)
> (In reply to David from comment #164)
> > If this remembers positions on a per-resolution base, does that mean that,
> > if I change the resolution, move the widgets around manually, and then
> > change back to the original resolution, these new positions that I set
> > manually would not apply?
> 
> Yes, they would not apply.

Then would it be possible to forget these per-resolution placements once the user moves a widget? Or to update them in terms of relative screen position after a manual move of a widget?

(In reply to David from comment #166)
> Then would it be possible to forget these per-resolution placements once the
> user moves a widget? Or to update them in terms of relative screen position
> after a manual move of a widget?

Actually, sorry, my MR only deals with Folder View icons, not with widgets.

I really don't know how to work with invent.kde.org. When I click on download, it offers me "Email patches" and "Plain diff". What should I need and how to use it?

(In reply to Nick Stefanov from comment #168)
> I really don't know how to work with invent.kde.org. When I click on
> download, it offers me "Email patches" and "Plain diff". What should I need
> and how to use it?

Get the plain diff, and apply it to /usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/FolderView.qml

Thanks! When I try to patch it I get thus:

File to patch: FolderView.qml
patching file FolderView.qml
Hunk #1 FAILED at 33.
1 out of 1 hunk FAILED -- saving rejects to file FolderView.qml.rej
can't find file to patch at input line 18
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/containments/desktop/package/contents/ui/FolderViewLayer.qml b/containments/desktop/package/contents/ui/FolderViewLayer.qml
|index 3dcb5c4b0f52fc69050ce6bd6a1ddb3c38994f5a..d764400039a6c00197634d654e36f58d23bef7c3 100644
|--- a/containments/desktop/package/contents/ui/FolderViewLayer.qml
|+++ b/containments/desktop/package/contents/ui/FolderViewLayer.qml
--------------------------

What command should I use? I tried with "patch -p1 < 608.diff"

(In reply to Nick Stefanov from comment #170)

I think it would be simpler to just replace the whole `/usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/FolderView.qml` file with contents of:

https://invent.kde.org/plasma/plasma-desktop/-/raw/d4627f12d1898a1c095452cc1534b51dd3cc5ad2/containments/desktop/package/contents/ui/FolderViewLayer.qml

Sorry, it's FolderViewLayer.qml not FolderView.qml. That was probably what was causing your patch error too.

Thank you. Unfortunately this is not worksing on my end. I even restarted the OS to no avail.

Created attachment 142592 [details]
Original layout

Created attachment 142593 [details]
Scaled down and rearranged

Created attachment 142594 [details]
Back to the original desktop

(Think my comment was gone as well, sorry if it pops up twice)

Confirmed. Doesn't work here. Have attached three screenshots:
Layout before switching (2560x1440)
(I left out the mess after switching to 1440x900)
Layout after rearranging the icons on the smaller screen
Messed up layout after switching back to 2560x1440

Here are the files, for double confirmation (.orig is the one I saved from the original install):
-rw-r--r-- 1 root root 14050 Okt 19 00:19 FolderViewLayer.qml
-rw-r--r-- 1 root root 14169 Okt 19 00:19 FolderViewLayer.qml.orig

I am on Plasma 5.18.5 (20_04); just for information.

I'm on Plasma 5.23 and it doesn't work for me as well.

Strange.

Could you check ~/.config/plasma-org.kde.plasma.desktop-appletsrc before and after each resolution change and post them?

Also I can't guarantee if it will work on 5.18, I haven't looked at the code that far back and certainly haven't tested it on that version.

Created attachment 142604 [details]
plasma-org.kde.plasma.desktop-appletsrc

Here you are :)

(In reply to Nick Stefanov from comment #181)
> Created attachment 142604 [details]
> plasma-org.kde.plasma.desktop-appletsrc
> 
> Here you are :)

Thanks. So the before one contains no data for icon positions, and the after one contains position data for 1280x800 matching the screenshot you gave me, and not for any other resolutions.

Could you switch to some lower resolution, make a copy of the config file, then switch back, make a copy again, and upload those.

Really sorry for making you do all this work

Created attachment 142605 [details]
plasma-org.kde.plasma.desktop-appletsrc

Sure, here you are :)

One thing to mention - when I apply your file, it scrambles all the icons and files on the desktop, even without restarting or turning off the monitor.

(In reply to Nick Stefanov from comment #183)
> Created attachment 142605 [details]
> plasma-org.kde.plasma.desktop-appletsrc
> 
> Sure, here you are :)
> 
> One thing to mention - when I apply your file, it scrambles all the icons
> and files on the desktop, even without restarting or turning off the monitor.

Okay so in these (attachment 142605 [details]) files, the positions= config is using the old format, which means my patch wasn't applied. If it was it would convert it to a format like in your attachment 142604 [details].

So what I should do?

Can you post the contents of /usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents?

How did you apply the patch? Did you make any changes in ~/.local/share?

Created attachment 142608 [details]
plasma-org.kde.plasma.desktop-appletsrc

Is this file with the new formatting?

I was using this fix and totaly forgot about it. I'm sorry.

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

No, I didn't made any changes in ~/.local/share?

(In reply to Nick Stefanov from comment #187)
> Created attachment 142608 [details]
> plasma-org.kde.plasma.desktop-appletsrc
> 
> Is this file with the new formatting?

No, the new formatting is going to look something like

positions={"1280x800":["1"\\,"12"\\,"desktop:/Editor"\\,"0"\\,"1"\\,"desktop:/Games"\\,"0"\\,"2"\\,"desktop:/Linux Files"\\,"0"\\,"3"\\,"desktop:/mozo"\\,"0"\\,"4"\\,"desktop:/Programs"\\,"0"\\,"5"\\,"desktop:/ "\\,"0"\\,"6"\\,"desktop:/Diction"\\,"0"\\,"7"\\,"desktop:/org.kde.konsole.desktop"\\,"0"\\,"8"\\,"desktop:/Text File.txt"\\,"0"\\,"9"\\,"desktop:/Computer"\\,"0"\\,"0"]}



> I was using this fix and totaly forgot about it. I'm sorry.
> 
> https://bugs.kde.org/show_bug.cgi?id=389705

Okay, so if you remove that workaround?

Please also post the file /usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/FolderViewLayer.qml on your system

Hmm, if I reinstall plasma-desktop again, will I acquire the new formatting file?

(In reply to Nick Stefanov from comment #190)
> Hmm, if I reinstall plasma-desktop again, will I acquire the new formatting
> file?

No, you'll have to reinstall plasma-desktop (and plasma-desktop-data if you're on Debian/Ubuntu/Neon), then replace /usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/FolderViewLayer.qml with https://invent.kde.org/plasma/plasma-desktop/-/raw/d4627f12d1898a1c095452cc1534b51dd3cc5ad2/containments/desktop/package/contents/ui/FolderViewLayer.qml

Also remove the workaround you were using

I removed it, reinstalled plasma-desktop (I'm on Arch} and I copied your file. Unfortunately the fix doesn't work. Do you need some files of mine?

Could you post the appletsrc file before/after a resolution change and switch back?

Created attachment 142611 [details]
plasma-org.kde.plasma.desktop-appletsrc

Here you are :)

Created attachment 142613 [details]
FolderViewLayer.qml with logging

Apply this new version of FolderViewLayer.qml, run plasmashell --replace in a terminal so we can monitor its output, place icons as you want on desktop, change some resolutions. Then post the output here.

Created attachment 142616 [details]
Screenshots and appletsrc files for comment 195

(In reply to Bharadwaj Raju from comment #195)
> Created attachment 142613 [details]
> FolderViewLayer.qml with logging
> 
> Apply this new version of FolderViewLayer.qml, run plasmashell --replace in
> a terminal so we can monitor its output, place icons as you want on desktop,
> change some resolutions. Then post the output here.

I have tried this on openSUSE TW, but the patch did not have the desired effect: Going from 4k to  2k, I got a scrollbar and going back the icons got rearranged.

Created attachment 142617 [details]
Plasma log

Here it is :)

Nick, looks like the patch isn't applied. There isn't any output from folderview in the log which should be there if the new patch is applied.

Postix, thanks, that log is helpful. I think I can see where things are going wrong.

Bharadwaj Raju, I don't know why, I replace the file with yours, it's a simple task, but it's not working...

(In reply to Nick Stefanov from comment #199)
> Bharadwaj Raju, I don't know why, I replace the file with yours, it's a
> simple task, but it's not working...

Here's how I did it:

```
wget "https://bugsfiles.kde.org/attachment.cgi?id=142613" -o "~/Downloads/FolderViewLayer.qml"

sudo mv /usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/FolderViewLayer.qml /usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/FolderViewLayer.qml.bak

sudo cp ~/Downloads/FolderViewLayer.qml /usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/FolderViewLayer.qml

plasmashell --replace
```

Created attachment 142618 [details]
FolderView.qml changed to not reset positions on flow/layoutdirection change (not FolderViewLayer.qml!)

Postix, try this. It's a changed version of FolderView.qml.

Created attachment 142619 [details]
Plasma log new FolderViewLayer.qml

Here's my log with the newest FolderViewLayer.qml. Keep in mind all my icons now are gone and the context menu is competely different:

https://i.imgur.com/HukjjUe.png

I can't even create a file.

(In reply to postix from comment #200)
> (In reply to Nick Stefanov from comment #199)
> > Bharadwaj Raju, I don't know why, I replace the file with yours, it's a
> > simple task, but it's not working...
> 
> Here's how I did it:
> 
> ```
> wget "https://bugsfiles.kde.org/attachment.cgi?id=142613" -o
> "~/Downloads/FolderViewLayer.qml"
> 
> sudo mv
> /usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/
> FolderViewLayer.qml
> /usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/
> FolderViewLayer.qml.bak
> 
> sudo cp ~/Downloads/FolderViewLayer.qml
> /usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/
> FolderViewLayer.qml
> 
> plasmashell --replace
> ```

Thanks, I do it the same way

Created attachment 142642 [details]
attachment-30285-0.html

Guys, I think you are making this issue more complicated than it has to be.

Yes, we might not be able to fix the "architecture" — my skill level is
certainly below that. But, it is actually fairly easy to fix using a simple
script, as I proposed some ~2 years back.
How? Once the resolution is set, and has remained for a few seconds, you
record the entire Desktop layout. E.g.:

1. Record the Desktop Layout for the current monitor and resolution
combination, either automatically or on-demand via clicking a "save" button
2. When the monitor and resolution combination changes, do nothing if the
combination is not found in backups
3. When a previously known combination is used, restore the Desktop Layout
from a backup
4. Detect changes to the Desktop layout. Every change may require deleting
all backed up combinations; alternatively, user should manually save a
backup by clicking a "save" button

Again, you could probably create a simple .sh script for this. I already
made one, but I have not used it since, so do not know if it still works.

- Jacob

On Tue, Oct 19, 2021 at 1:09 PM Nick Stefanov <bugzilla_noreply@kde.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=360478
>
> --- Comment #204 from Nick Stefanov <mo78@abv.bg> ---
> (In reply to postix from comment #200)
> > (In reply to Nick Stefanov from comment #199)
> > > Bharadwaj Raju, I don't know why, I replace the file with yours, it's a
> > > simple task, but it's not working...
> >
> > Here's how I did it:
> >
> > ```
> > wget "https://bugsfiles.kde.org/attachment.cgi?id=142613" -o
> > "~/Downloads/FolderViewLayer.qml"
> >
> > sudo mv
> > /usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/
> > FolderViewLayer.qml
> > /usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/
> > FolderViewLayer.qml.bak
> >
> > sudo cp ~/Downloads/FolderViewLayer.qml
> > /usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/
> > FolderViewLayer.qml
> >
> > plasmashell --replace
> > ```
>
> Thanks, I do it the same way
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

(In reply to Jacob from comment #205)

But we *are* fixing the underlying issue here. What you're proposing is a workaround, not a solution. Thanks to Postix's help, I've solved the problems which caused the MR to not work for others here.

Great news Bharadwaj Raju!!! Thank you very, very much!!!

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

It does get funny now. The last 20 or so comments are marked as 'spam' and are not visible by default.

There are some in here who have tried whatever they could to help. farid is right: learn to code. In this case case, however, not, because there is no design, no manifest, no requirements. The current implementation - though buggy - implements frightfully well the design. 
The design doesn't consider changing real estate while switching display. Since nobody has come forward to lay out rules for action to be taken in such situations, I'd be, well, more satisfied if the project marked this bug as 'won't fix' with "follows design [sigh]".

Let's not get bitter nor childish. "Use another DE if you don't like this" is pointless. We use it because we like it. 
"We don't have sufficient contributors" is probably honest, and sad. Though, be honest in that case and state what the project and the remaining contributors are able, willing and interested to do. 
Maybe the problem is me, my advanced age, being on Linux for almost 30 years, and implicitly assuming (still!) - or hoping - to be on an OS and a DE that is at least on par with some software from Redmond.

Apologies. Since I made the MR it is my responsibility and hence my fault that this hasn't been fixed yet. The MR is there, but there is a remaining issue which Nick faced (desktop icons rearranging themselves without any apparent external change) which I'm unable to reproduce and I am unfortunately too busy right now (for the next few months at least) to communicate and debug with him more. If anyone can reproduce the bug or coordinate with Nick to debug it, please take over the MR.

@Bharadwaj Raju
Many thanks for the update! That's what I wanted :)

If the patch solves the issue at least partially, would it not make sense to merge the patch as is? I started to test the patch and icons stay when I replug and unplug monitors or change the resolution of my screen. I f I read the history from October 2021 correctly, it mostly works for other people too.

Am I correct that a working way to test this is to replace 

/usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/FolderViewLayer.qml
with
https://invent.kde.org/plasma/plasma-desktop/-/blob/c06d7b0628cc31c1cd4b9d98f2ceb407c1741486/containments/desktop/package/contents/ui/FolderViewLayer.qml

and
/usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/FolderView.qml
with
https://invent.kde.org/plasma/plasma-desktop/-/blob/c06d7b0628cc31c1cd4b9d98f2ceb407c1741486/containments/desktop/package/contents/ui/FolderView.qml

I can see in the merge request a cpp file was also changed: https://invent.kde.org/plasma/plasma-desktop/-/blob/c06d7b0628cc31c1cd4b9d98f2ceb407c1741486/containments/desktop/package/contents/ui/FolderView.qml

that does not need recompiling?

(In reply to tomashnyk from comment #230)
> If the patch solves the issue at least partially, would it not make sense to
> merge the patch as is? I started to test the patch and icons stay when I
> replug and unplug monitors or change the resolution of my screen. I f I read
> the history from October 2021 correctly, it mostly works for other people
> too.

Correct, the patch solves the issue for most people. And it does solve the issue for Nick too, except on his machine it also introduces a new bug. I guess it could be merged, but I'm wary since it has this rare but known bug which actually makes the problem worse than before, not just status quo. If the bug was simply that it didn't solve the issue for some people while not making it *worse* for them, I would have much less problems with merging it. Right now only a few people have tested it and we found this issue, with a full release it might affect many more.

> I can see in the merge request a cpp file was also changed:
> https://invent.kde.org/plasma/plasma-desktop/-/blob/
> c06d7b0628cc31c1cd4b9d98f2ceb407c1741486/containments/desktop/package/
> contents/ui/FolderView.qml
> 
> that does not need recompiling?

That does need recompiling, aside from the QML files.

I'm prone to test it again. I should substitute just those two files (FolderViewLayer.qml and FolderView.qml), right?

(In reply to Bharadwaj Raju from comment #231)
> (In reply to tomashnyk from comment #230)
> > I can see in the merge request a cpp file was also changed:
> > https://invent.kde.org/plasma/plasma-desktop/-/blob/
> > c06d7b0628cc31c1cd4b9d98f2ceb407c1741486/containments/desktop/package/
> > contents/ui/FolderView.qml
> > 
> > that does not need recompiling?
> 
> That does need recompiling, aside from the QML files.

How would one go about recompiling it?

> I'm prone to test it again. I should substitute just those two files (FolderViewLayer.qml and FolderView.qml), right?

No, you need to compile plasma-desktop.

(In reply to tomashnyk from comment #233).
> How would one go about recompiling it?

Build plasma-desktop. Please see https://community.kde.org/Get_Involved/development#One-time_setup:_your_development_environment. For further help with compiling, the KDE Development chat on Matrix (https://webchat.kde.org) would be the right place.

Hmm, thanks, it's too complicated for me.I can try if someone give me a precompiled package.

Thanks, Bharadwaj Raju, for picking up this item and its code once again!

May I ask if the features have changed since your initial activities last year, please? My question should be permissible, since we had been informed by then, that
1. the patch stores pre-set arrangements on a per resolution base (and not pop up a workable desktop at a first-time switch to a new resolution; one that had not been used earlier)
2. the patch works on folder views only, not on widgets

Not to criticize your work, just asking for information purposes.

(In reply to Bharadwaj Raju from comment #234)
> (In reply to tomashnyk from comment #233).
> > How would one go about recompiling it?
> 
> Build plasma-desktop. Please see
> https://community.kde.org/Get_Involved/development#One-time_setup:
> _your_development_environment. 

Well, compiling is not easy - took me two days interminently hunting for outside-of-KDE dependencies, I only stumbled at this too late: https://www.hanyoung.uk/blog/kdesrc-build-on-ubuntu/ (and in the four months since that was written already caused that several other packages are needed).

But anyway, I suceeded and I have been using the patch for a few days now. At first I was confused that my icons dissappeared, then I noticed scrollbars (isn't this what caused Nick's icon to dissappear? It took me two days to notice the scrollbars).  I then manually re-arranged the icons to be visible on the desktop and it has been smooth since. So I think it is deffinitelly an improvement over the old behaviour, when icons would just be placed in random. So I would merge this as is.

However, for the future, I think it would be good to get rid of the scrollbars. My idea would be that when going from a larger resolution to a smaller, a saved state for that resolution would kick in. Then, if there are any icons that are not visible, these (and only these) icons would get re-arranged.

I didn't saw any scrollbars at all. But I'm agree it would be nice to push this changes and see what happens. They may be easily reverted if there are problems.

@tomashnyk@gmail.com
Can you give me the compiled patched file for I want to try this chabges a few days?

Read my earlier comments on 'real estate'.
Of course, it is possible, in case of decreased space, to add scroll bars. So KDE is the first DE in history to add scroll bars to a start screen, eventually? And when space increases, the icons are still hanging in the upper left corner.
And moving back from scare to original space, the scroll bars disappear?

There is light at the end of the tunnel, though: the project leaders have obviously come to understand the underlying design flaw. So Plasma 6 will surely solve this matter for good. Like with a full vector-oriented desktop. Plus the option to store and retrieve multiple desktop arrangements, e.g. for physically tiny screens like tablets, and large screens, like monitors. E.g. with an applet similar to the one for switching activities.

(In reply to Uwe Dippel from comment #239)
> Of course, it is possible, in case of decreased space, to add scroll bars.
> So KDE is the first DE in history to add scroll bars to a start screen,
> eventually? And when space increases, the icons are still hanging in the
> upper left corner.
No, they are not, positions of the icons are remembered when space increases - provided there has been such a resolution before.

> And moving back from scare to original space, the scroll bars disappear?
Yes. However, I too find scrollbars suboptimal (but still better than what is being done now). In commeny 237, I suggested a way to avoid scrollbars. However, when experimenting with it further, I think the behaviour  should be as follows.

1. Unless manually moved, icons are always top aligned (this is the current state). User can change whether they are left-or right align (also current state). This sets "corner alignment".
2. When resolution changes, a test should be made whether each icon is still visible on screen.
3. If an icon is is visible and it has not been automatically moved in a previous resolution change, keep it.
4a. If an icon is is visible and it has been automatically moved in previous resolution, move it back
4b. If an icon is not visible, test whether there is a saved resolution with a saved position of this icon.
5a. If yes, place it to a saved position.
5b. If not, place the icon to the opposite cornet of the "alignment corner", starting with icons that are th furthest from the "alignmnet corner", respecting whether icons are sorted into columns or rows.

The rationale: I think nobody wants icons to dissapper and most or all people want to keep placement of the icons as much as possible across different resolutions. As of now, when I move an icon in a given resolution and then change a resolution, that movement of the icon is reset. That is confusing and the above logic would solve this. I will try to illustrate it with a diagram. Lets have a 4x4 grid of icons. Numbers are positions, letters are icons:
  A   B   3   4
  C   D   7   8
  9 10   E  12
13 14   G   H

When the alignment is top left and into columns, transforming to 3x3 would yield this:
  A    B   G
  C    D   H
  7    8    E 
(H and G went off screen, so they get automatically re-arranged, from bottom right corner, which is opposite to the "alignment corner", starting with H, which was the most "off screen"), number 9 is occupied, so it i placed on 8, then G on 7 - if there was another icon, it would have gone to 8 and 7).

When the alignment is top left and into rows, transforming to 3x3 would yield this:
A    B    3
C    D    6
G    H   E
(the same as above, but now G and H are rearranged into rows, not columns)

Now imagine we move icons as follows (from the previous example with rows):
A    B   H
C    D   E
G    8   9
(so H and E were moved from 8 and 9 respecitvely to 3 and 6 - a property would need to be added tha would record whether placement is manual or automatic - only automatically placed icons would change place when going back to a higher resolution)

Now going back to 4x4 would give:
  A   B   H   4
  C   D   E   8
  9 10  11  12
13 14   G   16
(note H and E staying i their place set in 3x3, but G is rearranged).

An obvious question is what should happen when we have 4x4 grid and more than 16 icons. Actually, I think then a scrollbar is a good solution.


Also, I played with the current implementation a bit more
1) When one changes Alignment in "Desktop folder settings > Icons", it behaves in funny ways.  It seems to just flip X and Y coordinates. Previously, it would rearrange icons so they would all fit onto the screen. Now it happilly introduces scrollbars. I think it should behave according to the logic above using the property "manually|automatically" placed and should only change the position of  automatically placed icons. Further, it should not just flip their x and Y coordinates, but fill them one by one onto the visible untaken-by-other-icons area starting from the alignmnet corner (roughly the behaviour before this patch). The more I think about it, the property "manually placed" is quite crucial.

(In reply to Uwe Dippel from comment #239)a
> There is light at the end of the tunnel, though: the project leaders have
> obviously come to understand the underlying design flaw. So Plasma 6 will
> surely solve this matter for good. Like with a full vector-oriented desktop.
> Plus the option to store and retrieve multiple desktop arrangements, e.g.
> for physically tiny screens like tablets, and large screens, like monitors.
> E.g. with an applet similar to the one for switching activities.
Has actually such a decision taken place or is it just wishful thinking? I am not sure if I detect sarcasm in the above paragraph or not, please do not take this as an attack, I truly do not understand.

(In reply to Nick Stefanov from comment #238)

> @tomashnyk@gmail.com
> Can you give me the compiled patched file for I want to try this chabges a
> few days?
The compiled KDE desktop is 24 GB, I have no idea what to send you and if it would work. It being from compiled from source, I do not have any installation package or anything.

@tomashnyk@gmail.com
I see, thanks :)

"provided there has been such a resolution before"
Exactly my point. One needs to rearrange layout on a new, larger screen. We have a solution for this: storage for each resolution after a manual rearrangement.

Sarcasm? In this case not. Rather sneaking in my concepts. I was turned down before to contribute (not my contributions!)
Vector-orientation is a must; we don't want to have to rearrange for minor changes. And then mapping the vector-image on the pixels (screens will be pixel-oriented for quite some time!). With tiny screens of high resolution, we use the ratio of pixels to dpi of the hardware. And we allow the user to add - like activities - new layouts for other of such ratios. Whenever a previously unknown appear, we'll use the layout of the closest. With the user being able to always add another one. 
This finally also solves my longlasting problem with panels and their sizes. When they take too much space here, and become unmanageably small there. Of course, including notifications and stuff. 
Add landscape and portrait layout, and we'll attain the level of Android of almost ten years ago.
(THIS was sarcasm.)

I am not sure the vector based approach would be foolproofer than what we have now. Let's take my example from above:

 A   B   3   4
  C   D   7   8
  9 10   E  12
13 14   G   H

where would you put H if the display shrinks? I definitely would not want the whole thing to just shrink so everything would be relatively in the same position but the icons would be tiny.

I agree that DPI should be taken into account, but even that is not enough. For example, I either use my laptop on its own or docked into external monitor - in this setting, I still use the laptops display but the screen is much farther from my head. Thus for this scenariou, I would need to make everything on the laptop screen bigger. I do not think it reasonable to expect this would just set itself up automatically. The best we can hope for would be a system that would easily enable custom-configuration under specific  circumstances. Display configuration allows this already, but just for display configuration - I would love to make my whole setup change slightly when I dock my laptop.

(In reply to tomashnyk from comment #243)
> I definitely would not want
> the whole thing to just shrink so everything would be relatively in the same
> position but the icons would be tiny.

Something's gotta give. 
I *think* so far I have given a number of, though pertinent, comments to a bug on a bug tracker. As much as I'd like to detail my answer and further the discussion, including your comment, it ought to be taken elsewhere. 

My involvement is kind of over here, since I was finally (after some years, though) made to understand that my early assumption of a lackadaisical design was confirmed, and that no patch can be written to help this defect, and that the workarounds (my favored one mentioned above) would necessarily be of a lousy nature. 
I think it's the time to leave this mess behind, the workaround with the scrollbars-if-needed is one of the better ones, while we wait for a new design; for Plasma 6. 

I would be open for any reasonable discussion, including how to tackle the problem mentioned by you, as I wrote earlier; though not in this by now dated bug report. 
I will not undertake any efforts on my own, since my experiences in the transition from 3.5 to 4. Then, that is more than 15 years ago, KDE dropped 3.5 with a great idea: offering a single desktop; for all sizes from - let's say - 4" to 24"; same user experience irrespective of (the by then recent) tablet or PC use. 
Funny enough, and of course(!) the same problem popped up very early on in the design outlines in those days. Any reasonable approach had been manhandled, and so the project has been half-dead since then. I mean, the living half, the PC desktop on a large monitor, is very much alive, thanks to God! so I could use it throughout the last 15 years. 

Case (bug report) closed for me. It's a simple WON'T FIX / WORKAROUND.

> 
> I agree that DPI should be taken into account, but even that is not enough.
> For example, I either use my laptop on its own or docked into external
> monitor - in this setting, I still use the laptops display but the screen is
> much farther from my head. Thus for this scenariou, I would need to make
> everything on the laptop screen bigger. I do not think it reasonable to
> expect this would just set itself up automatically. The best we can hope for
> would be a system that would easily enable custom-configuration under
> specific  circumstances. Display configuration allows this already, but just
> for display configuration - I would love to make my whole setup change
> slightly when I dock my laptop.

I think this merge request really should be accepted. After living with this patch for ten days and not having to reorder my icons even once, I must say it works superbly (and actually scrollbars when there are more icons thatn the chosen grid supports are quite usable). I really think merging this would mean a much improved behaviour for a lot of users (remember the 57 users just on this bug report). @Bharadwaj Raju said  @Nick Stefanov (and @Uwe Dippel ) both had troubles but neither of them has compiled the patch as can be seen in their comments:

(In reply to Nick Stefanov from comment #235)
> Hmm, thanks, it's too complicated for me.I can try if someone give me a
> precompiled package.


(In reply to Uwe Dippel from comment #160)
> Alas, I was a developer some 15 years ago. Now I am retired, and don't feel
> able to do anything of this kind. 

So I think we have zero reports that this breaks things and at least one report that this greatly improves things (me). 5.24 was released less then two months ago, so if we merge this now, we have at least two months to gather reports if this breaks things in unforeseen ways. However, given how broken this is right now without this patch, I would be surprised if that was worse than what we have now. 

My setup is actually fairly complicated, I have:
A) Full HD laptop
B) 4K monitor
C) QHD monitor
D) Full HD projector

I use combinations of 
1) A
2) ABC
3) ABCD (when kde is configuret to turn of BC)
4) AD
(and during testing I tried AB and AC)

Icons just stay where they are. I have them primarily on A. When I put an icon on B and then unplug it, the icon happily migrates to A. When I plug B back, the icon goes back to B.

Bharadwaj Raju tested it on my machine remotely. But it was only a files overwrite. I hope it'll work fine if it's compiled.

Sorry for the delay. I'm barely able to check my KDE emails due to my other work.

(In reply to Uwe Dippel from comment #236)
> May I ask if the features have changed since your initial activities last
> year, please? My question should be permissible, since we had been informed
> by then, that
> 1. the patch stores pre-set arrangements on a per resolution base (and not
> pop up a workable desktop at a first-time switch to a new resolution; one
> that had not been used earlier)

My patch doesn't affect what happens when a new resolution is encountered. All it does is save different position info for each resolution, and pick the appropriate one when a previously-encountered resolution is used again. For new resolutions the existing behavior of trying to just fit icons is preserved.

> 2. the patch works on folder views only, not on widgets

Correct.

---

(In reply to Nick Stefanov from comment #246)
> Bharadwaj Raju tested it on my machine remotely. But it was only a files
> overwrite. I hope it'll work fine if it's compiled.

and

(In reply to tomashnyk from comment #245)
> I think this merge request really should be accepted. After living with this
> patch for ten days and not having to reorder my icons even once, I must say
> it works superbly (and actually scrollbars when there are more icons thatn
> the chosen grid supports are quite usable). I really think merging this
> would mean a much improved behaviour for a lot of users (remember the 57
> users just on this bug report). @Bharadwaj Raju said  @Nick Stefanov (and
> @Uwe Dippel ) both had troubles but neither of them has compiled the patch
> as can be seen in their comments:

The files needed for the functionality of patch are just QML. So far there are no C++ changes other than adding debugging (which is still important, but not to the functionality). So I don't think compiling would change the behavior.

Further testing with Nick seems to show that the problem is solved now. I'll go ahead with trying to get the MR merged.

Thanks for you great work Bharadwaj Raju!!!

Git commit 2dca17060c06f85abc365bab9484ee4446d78772 by Nate Graham, on behalf of Bharadwaj Raju.
Committed on 12/04/2022 at 15:01.
Pushed by ngraham into branch 'master'.

Folder View: save desktop containment icon positions on a per-resolution basis
FIXED-IN: 5.25

M  +1    -14   containments/desktop/package/contents/ui/FolderView.qml
M  +29   -3    containments/desktop/package/contents/ui/FolderViewLayer.qml
M  +1    -0    containments/desktop/plugins/folder/positioner.cpp

https://invent.kde.org/plasma/plasma-desktop/commit/2dca17060c06f85abc365bab9484ee4446d78772

Wonderful to see this resolved! The message seems to refer to folder view though: Does the solution also address widgets placed on the desktop? If yes this should be good.

(In reply to Mircea Kitsune from comment #251)
> Wonderful to see this resolved! The message seems to refer to folder view
> though: Does the solution also address widgets placed on the desktop? If yes
> this should be good.

It does not, actually. That would require a separate fix.

(In reply to Bharadwaj Raju from comment #252)
> It does not, actually. That would require a separate fix.

Thanks for clarifying. The problem I was experiencing had to do with the system monitor widgets I place on the right side of the screen, they'd get shrunken and repositioned whenever a fullscreen game lowered the resolution, once exiting the game and returning to normal resolution they'd remain positioned in the upper-left corner in a box representing the resolution the game temporarily switched to. I'm glad at least Folder View works now, but it would be appreciated if a fix for plasmoids was possible as well. I'll set this to reopened with that in mind, as the issue was also about widgets on the desktop.

Excellent to see that a fix made it out! I updated the bug to reflect the problem now.

Especially as devices like the steam deck become more mainstream, we will start to see issues like this show themselves more.

Many bugs are marked as duplicated of this bug. This bug got marked as solved, but many of the "duplicates" are not solved since they are about different problems.

(In reply to David from comment #256)
> Many bugs are marked as duplicated of this bug. This bug got marked as
> solved, but many of the "duplicates" are not solved since they are about
> different problems.

All the (non-folder-view-related) duplicates I see are about desktop widgets moving around. Now this bug has changed its title to be about desktop widgets and has been reopened to track that issue.

widget positions were already done on a per-resolution basis earlier, so it should already be fixed. If it's not working for you, it's a bug in the implementation, and we should get a new bug report for it.

Let's let this bug report be closed now that everything that it was tracking is at least supposedly fixed. :)

(In reply to Nate Graham from comment #258)
> widget positions were already done on a per-resolution basis earlier, so it
> should already be fixed. If it's not working for you, it's a bug in the
> implementation, and we should get a new bug report for it.
> 
> Let's let this bug report be closed now that everything that it was tracking
> is at least supposedly fixed. :)

From what I understood, bugs like 388863 are not fixed, yet still marked as duplicated. Lots of the duplicates are about the widgets, which are not currently done on a per-resolution basis.

Bug 388863 is about desktop icons, right? So it should be solved with the new folder view patch.

For desktop widgets I just looked and found it was actually fixed thanks to Marco Martin in https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/385, included in 5.22. Are there still problems on Plasma 5.22 and later with desktop widgets moving around after resolution changes? I tested a bit and it seemed to work fine at least here.

In comment 122 of this bug report, you can see the commit by Marco Martin to make widgets remember their positions per-resolution.

Again, if something is still not working for you, let's get a new bug report about it.

(In reply to Nate Graham from comment #261)
> In comment 122 of this bug report, you can see the commit by Marco Martin to
> make widgets remember their positions per-resolution.

Sorry about that, was a little confused and must have missed it. Then this should be fully solved. Thanks for all the work on finding a solution!

We can un-dupe them. Which ones do you think are about different problems?

(In reply to Nate Graham from comment #263)
> We can un-dupe them. Which ones do you think are about different problems?

From some very basic testing, looks like the bugs I had in mind are solved in the latest version, although I haven't tested comprehensively so will file a new report if I find it working incorrectly.

Git commit 8f85c4658adfdf7a01c591afd79baa9eed8b79dd by Nate Graham, on behalf of Bharadwaj Raju.
Committed on 17/04/2022 at 18:55.
Pushed by ngraham into branch 'Plasma/5.24'.

Folder View: save desktop containment icon positions on a per-resolution basis
Related: bug 354802
FIXED-IN: 5.24.5
(cherry picked from commit 2dca17060c06f85abc365bab9484ee4446d78772)

M  +1    -14   containments/desktop/package/contents/ui/FolderView.qml
M  +29   -3    containments/desktop/package/contents/ui/FolderViewLayer.qml
M  +1    -0    containments/desktop/plugins/folder/positioner.cpp

https://invent.kde.org/plasma/plasma-desktop/commit/8f85c4658adfdf7a01c591afd79baa9eed8b79dd

Great news, thanks for that!!!

You're welcome. I just wanted to get in a few more days of testing before pulling the trigger :)

Time will show :)
Up the Irons!!!

I filled a follow-up bug based on my comment 240. It proposes a solutio to deal with the situation that icons still get scrambled when a new previously unseen resolution is used and that moving an icon is not carried over changes between known resolutions: https://bugs.kde.org/show_bug.cgi?id=453141