Additional Observarions on my part after the dissapointment that it was still not fixed with 5.24.5:

1: you can put the file where the desktop icon positions are stored: "~/.config/plasma-org.kde.plasma.desktop-appletsrc" in readonly mode and icons still get scrambled, even though the file does not seem to be changed. 

2: when executing the restart commands the desktop icons can stay in a different state then currently shown when u have focus on a window,
clicking on the desktop shows icons on different positions then when a window is in focus, this stopps after a while and the "desktop-state" when no window is in focus takes over for good

3: i have not completly figured out when this starts happening as you can create a fresh user and it doesnt happen for it until some point when it happens once, then it seems to happen everytime u just restart the shell or login. Deleting the ~/.config file does not have any effect on it either having to recreate ur desktop.

4: happens with no activitys and on single desktops, plasma uses systemd-startup.

At first I think somene have to look at plasma-org.kde.plasma.desktop-appletsrc and why it's overwritten at every boot.

It's now working for me, whereas I was able to reproduce Bug 354802, so there must be something different about our setups.

I have a few questions:
1. Is the layout always reset such that the items are in alphabetical order, with folders before files?
2. Are you using a laptop or a desktop?
3. How many screens do you have connected,
4. In your ~/.config/plasmashellrc file, does the contents of the "[ScreenConnectors]" section change after you reboot?
5. In your ~/.config/plasma-org.kde.plasma.desktop-appletsrc file, does the contents of the line beginning with "positions=" change after you reboot?

Hmm, it starts to happen more often.
1. No they are not in alphabetical order
https://i.imgur.com/EuiptQl.png
They have to be like that:
https://i.imgur.com/xvv5Mwk.png
2. Desktop.
3. Single screen, never have been using more.
4. No 
5. I don't know, I don't have the observations yet.

I wonder if this is an issue when using the "Arrange in columns" setting.

If you change your Folder View settings to use "Arrange in rows", manually move the icons to a row at the top of the screen, and then reboot the machine or restart Plasma, do the icons stay in the the same places?

This bug happens on all configs (row / clolumn) align fixed positions, doesnt matter.
The icons change position and wanna be in a different state than the one saved in the appletrc "positions=" line.

YES if u restart plasmashell and dont have the file in readOnly mode that line gets rewritten, but even if u put it in readOnly the icons shift and the config file shows different positions that those displayed on the desktop.

There is only 1 screen at all times and no the scramble does not follow alphabethical order or reverse or anything like that...
when in row alignment (with manual sorting) icons in a column: turn into some sort of staircase with only the upper left staying where it was
A                                            A
B                      ->                          B
C                                                          C

Also there is no "[ScreenConnectors]" section in the ~/.config/plasmashellrc file.
As i said on new user it is not reproducable immediatly, just when u start using that user after a while soemthing happens (mb plasma crashes or doesnt shutdown properly or smthing) and after that icon scrambles happen almost everytime plasmashell is restarted.

I backed up the ~/.config/plasma-org.kde.plasma.desktop-appletsrc file from fresh user where it did not happen, when it started happening i replaced it with the backup, that did NOT fix it either: the icons keep scrambling every restart.

Mb its  note worthy but the desktop in question always uses "large" label width for the icons.

I have strictly  always the the same scrambled position as that described by William 2022-05-25 16:07:54 utc.
My initial bug was 452506 with the changes in the file plasma-org.kde.plasma.desktop-appletsrc (see 452506
But my two machines with the problem have each an additional screen
An additional observation :
Sometimes after boot, when the start screen closes and the desktop opens we can see in reality two desktop screen :
-the first one during half a second with the icons scrambled
-the second one with the icons at the right place
I wanted to go further and find why the system displays two screens but sorrily I did find anything in journalctl.
But this is for me the way.
And for time to time sometimes the second screen display does not come and the icons remain scrambled

(In reply to Nate Graham from comment #3)
> It's now working for me, whereas I was able to reproduce Bug 354802, so
> there must be something different about our setups.
> 
> I have a few questions:
> 1. Is the layout always reset such that the items are in alphabetical order,
> with folders before files?
> 2. Are you using a laptop or a desktop?
> 3. How many screens do you have connected,
> 4. In your ~/.config/plasmashellrc file, does the contents of the
> "[ScreenConnectors]" section change after you reboot?
> 5. In your ~/.config/plasma-org.kde.plasma.desktop-appletsrc file, does the
> contents of the line beginning with "positions=" change after you reboot?

5. Yes, they change on reboot. Today my icons get scrambled again and there's changes in this section.

Before:
https://pastebin.com/U6m2mbAJ

After:
https://pastebin.com/LfLaMzvs

This gets weirder and weirder:
https://youtu.be/y0-8611IIQ8

I even can't rearrange my icons...

Created attachment 149335 [details]
Scrambled icons and wrong background after reboot

Created attachment 149336 [details]
Desktop before reboot / after PlasmaConfigSaver

Are we now running into something else, or am I at the wrong report? Earlier we were at 'scrambled at reboot' AFAIK. Now we are at Plasmashell Start? 
I still experience the 'at reboot' st times. Like today, see attachment. Everything in 'Desktop' plus my desktop icons are placed in a wrapped fashion above the default desktop background (see attachment).
Then I have to 'Customize Layout', add the PlasmaConfigSaver and restore to my last saved desktop layout (see attachment). 

Please, inform me if this is not the appropriate bug, and the 'RESOLVED CLOSED' (LOL) original was reopened elsewhere, thanks.

(In reply to Uwe Dippel from comment #12)
> Are we now running into something else, or am I at the wrong report? Earlier
> we were at 'scrambled at reboot' AFAIK. Now we are at Plasmashell Start? 
> I still experience the 'at reboot' st times. Like today, see attachment.
> Everything in 'Desktop' plus my desktop icons are placed in a wrapped
> fashion above the default desktop background (see attachment).
> Then I have to 'Customize Layout', add the PlasmaConfigSaver and restore to
> my last saved desktop layout (see attachment). 
> 
> Please, inform me if this is not the appropriate bug, and the 'RESOLVED
> CLOSED' (LOL) original was reopened elsewhere, thanks.

this is the correct bug report, i just named it "on plasmashell start" as that is precisly what is happening during reboot, relogin or via commands, the part in question is the plasmashell startup that messes things up.
Mb u can run the command "kquitapp5 plasmashell && kstart5 plasmashell" and see if it happnes to u with that aswell.

Anyways the old report was closed and u are right here, welcome to the a bug that is now 7 years old,  twice marketed as fixed and still some process during startup does not respect icon positions and on top of all also tries overwrites a users config file that it shouldnt ever even attempt to write to. 

here is to another 6 years of noone bothering to fix the most important issue in KDE plasma and why windows users wont switch, quote "if it cant even remember my desktop icons i cant trust it to store anything, even if microsoft collects all my data at least it does know how to store stuff lol" try to install xfce or zorinOS if u dont want to scare them away. kde just doesnt prioritize this kind of stuff - every other company wouldve had complete featurefreeze and stopped all further coding till this is fixed but opensource u cant do that so every1 just does what he likes to do.  even throwing money at this thing does nothing,... i guess i have to learn coding and fix it myself, even if that takes 3 years it probably is faster

Thanks, William.
Same-same.
I can't roll out any desktop that maybe next time doesn't look at all like its previous settings. 
Unfortunately, the PlasmaConfigSaver as additional widget isn't there, blablabla, so no chance anyone will accept this crxx as their desktop (though everyone loves it once they've seen mine!). 

Let's just keep our fingers crossed that some fine day the KDE people understand that you can't sell even a Rolls. At least not as long as from time to time its wheels just fall off.

(In reply to William from comment #6)
> There is only 1 screen at all times and no the scramble does not follow
> alphabethical order or reverse or anything like that...
> when in row alignment (with manual sorting) icons in a column: turn into
> some sort of staircase with only the upper left staying where it was
> A                                            A
> B                      ->                          B
> C                                                          C
> 

I have a Kubuntu 22.04 Desktop that has just been upgraded from 20.04.  This isn't the first upgrade; the original install was quite some years ago, but I've kept the home directories intact.  I don't know; it could be 5 - 10 years old.

After a couple of reboots, the above issue showed up and stayed.  FWIW, I also had the issue in comment 10 occur very randomly in 20.04.
My initial fix in 22.04 was to go through the .local, .config and .cache and delete files that looked old and crufty.  That fixed the staircase problem noted above, but the icons still moved around on each reload of the desktop.

My next fix was to backup and delete plasma-org.kde.plasma.desktop-appletsrc.  On reboot, the file was autogenerated again (I had to reconfigure the desktop to my preference again).  I seem to have icons staying in one place now.  I've done numerous reboots over a period of days and it seems stable. 

I note that the new  plasma-org.kde.plasma.desktop-appletsrc and the old file look very different.  Also the date stamp on the old file was updating with each reboot (it wasn't old and static).

Same problem for me on EndeavourOS, although the pressing issue isn't icons on the desktop (as I don't have a lot on my desktop) but settings for widgets. I have a panel added to the top of my screen with system info (CPU usage, HDD space and activity, memory usage etc.) and each time Plasma is reloaded the settings for those widgets are reset. Like others in this thread, I noticed changes made to plasma-org.kde.plasma.desktop-appletsrc each time, however even making the file read-only doesn't prevent the widgets being reset. I was able to reproduce the issue even by deleting the existing plasma-org.kde.plasma.desktop-appletsrc, restarting Plasma, and then simply adding a single new panel with a single "Toal CPU Usage" widget, changing its settings, and upon restarting Plasma the widget is reset to defaults.

KDE Plasma Version: 5.25.3
KDE Frameworks Version: 5.96.0
Qt Version: 5.15.5
Kernel Version: 5.18.15-arch1-1 (64-bit)
Graphics Platform: X11

I've been experiencing this since I set up a new laptop in January 2021. Laptop is an Asus UX563F which has a second screen under the touchpad. It's a vertical phone sized screen rotated 90 degrees to make a touchpad and it's a really handy place to put app icons, except that Plasma scrambles them.

In Plasma System Settings -> Display Configuration, the main laptop screen is 3840x2160 at 60hz. Secondary screen is 1080x2160 at 50hz, rotated 90 degrees anticlockwise. There's a 150% global scale applied.

This is an Optimus set-up so I'm running Xorg with modesetting drivers and Bumblebee to switch between Intel and nVidia GPUs.

For all this time, I've barked up many trees trying to figure out if this is caused by the screen rotation (XrandR under the hood I assume?), the modesetting/bumblebee configuration, the global scale, etc. I've read through all of the comments in this bug report, https://bugs.kde.org/show_bug.cgi?id=354802 , and a bunch of other duplicates, and like many others I've spent some time trying to work around the ever changing plasma-org.kde.plasma.desktop-appletsrc file but this seems to be updated regularly when all sorts of things happen, it's not just for desktop icon arrangement so readonly states etc don't cut it for me. Additionally, adding scripts to shutdown/startup procedures to dynamically fiddle with this isn't enough because closing the laptop lid or just turning off and back on the secondary screens doesn't trigger those events.

What I've found though, and hopefully this is useful to somebody with more knowledge of these scripts than me, is that if you open a Konsole and restart plasmashell:

$ kquitapp5 plasmashell
$ kstart5 plasmashell

Then when you do something to trigger the icon scramble, e.g. close and open the lid or turn off and on the second display, the Konsole floods with interesting errors like this:

file:///usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/FolderItemDelegate.qml:382:21: Unable to assign [undefined] to bool
file:///usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/FolderItemDelegate.qml:497:25: Unable to assign [undefined] to bool

and this:

file:///usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/FolderItemDelegate.qml:320:17: QML Label: Binding loop detected for property "width"

FolderItemDelegate.qml appears to be used for generating the icons in folder views, which fits with this being a bug for people who run the desktop as a folder view.

Lines 382 and 497 reference model.isLink and model.selected so I'm wondering whether model isn't fully set-up yet at the time this script runs. If these couple of lines throw errors because they're expecting to read properties that don't yet exist, then other lines more related to positioning could also be looking at properties that simply don't yet exist. Which makes sense if XrandR for example hasn't yet finished rotating the output.

There's also FolderView.qml in here which I assume sets up the main container for these icons to sit in. Interestingly this seems to be where all of the drag handling code sits, including an onPositionChanged handler that I think is designed to figure out where in the grid to bounce icons to when dragging them around. Is it possible that this routine is firing prematurely during the initiation phase and bouncing icons to grid locations before the screen sizing and rotation has happened, because their current position isn't valid at the point of firing?

Lots of interesting code in these two files and though I might once again be barking up the wrong tree, I do feel it worth somebody with more knowledge of this stuff looking over it.

Hope this in some way helps.

Very interesting finding!
But I'm wondering why is this lack of interest from the devs? People find some interesting things - nobody cares and nobody tries to find the culprit. It's beyond me, really.

Created attachment 151555 [details]
attachment-28934-0.html

I'd seriously wished, the project declared formally that it's no longer
targeting situations of larger roll-outs. Because that's what it
effectively is.
Recently I filed a number of bugs against Chromium snap; bugs that have
relatively simple workarounds, but completely forbid a roll-out to Tom,
Dick and Harry (misleading wording, necessitating command line, etc).
What I found was, that they'd been filed back in 2020. So far no action.

(I know some will consider this post 'spam'. It simply looks like we have
no target 'project as a whole'.)

On Wed, 24 Aug 2022, 17:55 Nick Stefanov, <bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=454345
>
> --- Comment #18 from Nick Stefanov <mo78@abv.bg> ---
> Very interesting finding!
> But I'm wondering why is this lack of interest from the devs? People find
> some
> interesting things - nobody cares and nobody tries to find the culprit.
> It's
> beyond me, really.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

I have had a similar bug, but on multi monitor setups.

(In reply to Nick Stefanov from comment #18)
> Very interesting finding!
> But I'm wondering why is this lack of interest from the devs? People find
> some interesting things - nobody cares and nobody tries to find the culprit.
> It's beyond me, really.

Because it's a hard bug to reproduce. Try as I might, I can't seem to get it on my system. The last one (resolution change) I could at least reproduce, so that was feasible to fix.

Still, thanks very much for the findings, Ric Grant — maybe I can try some fixes using all these clues, but it'll just be flying blind since again I can't reproduce it at all here.


(In reply to Uwe Dippel from comment #19)
> I'd seriously wished, the project declared formally that it's no longer
targeting situations of larger roll-outs. Because that's what it
effectively is.

We'll declare it tomorrow, thanks for the helpful suggestion Uwe.

(In reply to Bharadwaj Raju from comment #21)
> Because it's a hard bug to reproduce. Try as I might, I can't seem to get it
> on my system. The last one (resolution change) I could at least reproduce,
> so that was feasible to fix.
> 
> Still, thanks very much for the findings, Ric Grant — maybe I can try some
> fixes using all these clues, but it'll just be flying blind since again I
> can't reproduce it at all here.

Do you have a second monitor? I've actually never tried icons on the primary display myself (perhaps this only happens when there are no icons on there in fact!), but from everything I've read throughout all of these various bug reports, this is always a secondary screen issue.

In case it aids with replication, I'll also attach a screenshot of how I group my icons on this secondary display. I've seen reports that having icons on the first row or in the first cell helps, though this never did for me. Every time when I close the lid and trigger this screen turning off and back on, the icons all end up rearranged and I've to shuffle them back to these locations.

Created attachment 152072 [details]
Icons arranged neatly on secondary display before Plasma shuffles them on screen turn on

(In reply to Ric Grant from comment #22)
> Do you have a second monitor? I've actually never tried icons on the primary
> display myself (perhaps this only happens when there are no icons on there
> in fact!), but from everything I've read throughout all of these various bug
> reports, this is always a secondary screen issue.

Will try. I do have a second monitor but my desktop case only has one VGA port, so I'll have to get an adapter of some kind, maybe.

(In reply to Bharadwaj Raju from comment #24)
> Will try. I do have a second monitor but my desktop case only has one VGA
> port, so I'll have to get an adapter of some kind, maybe.

Just been experimenting. It seems I can do whatever I like on the primary display - icons stay where intended during reboots and lid closure. But the icons on the secondary screen still, even while the primary screen icons behave, get shuffled around. Sometimes they shuffle instantly, other times they look correct until you try to click on one and then they all shuffle. Most weirdly, clicking on the primary screen sometimes then corrects the positions on the secondary but clicking back on the secondary shuffles them again until after a few clicks they just remain in their shuffled position.

Another potential clue - if I select my icons and drag them to the primary display, they drop into a long row instead of retaining their abstract order. As if the positions aren't carried over when moving from one screen to another and the new screen just sets them up as new icons at natural positions. I'm wondering therefore, if what's actually happening when the secondary screen is turned off and back on again is that Plasma sets this up as a new screen, moves the icons over to it, and they all just take on a default position?

I have a theory which is borne out by https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2120.

Bug 354802 fixed the bulk of the bug by making layouts get remembered on a per-desktop-dimensions basis.

However the "remember things on a per-desktop-dimensions basis" feature itself is buggy because the desktop dimensions change during startup, for example when the panel appears. Because that's animated, there are a bunch of intermediate states. There's code to batch them up, but it's apparently rather buggy, and doesn't work well if initial startup is slow beyond a certain level. So the "save/restore positions" code can get confused by these intermediate states. We replaced one bug (in Bug 354802) with another, less severe one. But still a bug, so positions aren't remembered in 100% of cases.

We have the same issue with widget positions, which https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2120 is trying to fix. But it also appears to fix this as well, since now both bugs are the same: caused by repeated desktop dimension changes at startup.

(In reply to Nate Graham from comment #26)
> I have a theory which is borne out by
> https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2120.
> 
> Bug 354802 fixed the bulk of the bug by making layouts get remembered on a
> per-desktop-dimensions basis.
> 
> However the "remember things on a per-desktop-dimensions basis" feature
> itself is buggy because the desktop dimensions change during startup, for
> example when the panel appears. Because that's animated, there are a bunch
> of intermediate states. There's code to batch them up, but it's apparently
> rather buggy, and doesn't work well if initial startup is slow beyond a
> certain level. So the "save/restore positions" code can get confused by
> these intermediate states. We replaced one bug (in Bug 354802) with another,
> less severe one. But still a bug, so positions aren't remembered in 100% of
> cases.
> 
> We have the same issue with widget positions, which
> https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2120 is
> trying to fix. But it also appears to fix this as well, since now both bugs
> are the same: caused by repeated desktop dimension changes at startup.

Ohhh this sounds promising! Your mention of animation states and the references in https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2118 to resolution changes happening during initiation fits with the console outputs I noted in my https://bugs.kde.org/show_bug.cgi?id=454345#c17 comment. It does sound a lot like we might see this fixed in an upcoming release!!? :-D.

If all goes well, it will be fixed in the final Plasma 5.26 release.

do desktop dimensions also change during plasmashell startup? the MergeRequest https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2118 indeed sounds pormising but lets pls not close the bug until it is fixed for sure. 
This issue occured on all gpus all monitors (single or multi monitor) and all distributions (i tried quite a bit of KDE installs), it is 100% reproducable with the posted plasmashell restart commands (so not only during KDE startup, just plasmashell startup

im still baffled how its hard to reproduce while it happens to me every KDE install ever within a week of using it, nothing special (no power user stuff or customizations). I know how to install latest KDE Neon unstable if it lands there i can check it if i have the time otherwise idk how to verify early if this MR would help

Git commit 59bf0f5a2081ed49a32a34083b7f5a9f0792358b by Nate Graham, on behalf of Marco Martin.
Committed on 23/09/2022 at 22:21.
Pushed by ngraham into branch 'Plasma/5.26'.

Introduce a lock that blocks relayouts and config writes

The resize of the layout area can happen either by screen resolution
change or available screen area change (a panel appears or is resized)
This is not an atomic operation, as width and height are usually set in
2 different operations, and even worse the layout area is resized to
match the available one with an animation, so many intermediate resizes
that should never cause a relayout happen.

In normal operation an event compression timer limits the actual
relayouts to hopefully one, but if the system is really slowed down
(for instance, startup) the timer may expire and cause relayouts in
non useful sizes, losing the needed configuration.

In combination with
https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1150

The lock blocks all relayout and config writes when the size of the
layout area doesn't correspond to corona availablescreenrect, which are
the only "settled" cases.


(cherry picked from commit ef57cd3d50f729f22558a20b03172da539e3bb71)

M  +23   -2    components/containmentlayoutmanager/appletslayout.cpp
M  +7    -0    components/containmentlayoutmanager/appletslayout.h

https://invent.kde.org/plasma/plasma-workspace/commit/59bf0f5a2081ed49a32a34083b7f5a9f0792358b

Git commit 22fa69d96d64422318e83cc57d9ed1d0a08c17b0 by Nate Graham, on behalf of Marco Martin.
Committed on 23/09/2022 at 22:21.
Pushed by ngraham into branch 'Plasma/5.26'.

Use relayout locking

This makes use of the layout locking freature introduced in
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2120
The resize of the layout area can happen either by screen resolution
change or available screen area change (a panel appears or is resized).

This is not an atomic operation, as width and height are usually set in
2 different operations, and even worse the layout area is resized to
match the available one with an animation, so many intermediate resizes
that should never cause a relayout happen.

A compression timer limits the actual relayouts to hopefully one,
 but if the system is really slowed down
(for instance, startup) the timer may expire and cause relayouts in
non useful sizes, losing the needed configuration.

The lock blocks all relayout and config writes when the size of the
layout area doesn't correspond to corona availablescreenrect, which are
the only "settled" cases.


(cherry picked from commit bd676333cf57659bc885928afe5d3fe908589e79)

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

https://invent.kde.org/plasma/plasma-desktop/commit/22fa69d96d64422318e83cc57d9ed1d0a08c17b0

still happening on manjaro stable 5.26.2 changes did affect the behavoir instead of:
A                                            A
B                      ->                          B
C                                                          C

it now scrambles the icons in a different way:
A                                                            A
B                      ->                          B
C                                            C

sry but this is not fixed.- something still wrong here. why is it so hard to remove any logik that touches that desktop-appletrc file during plasmashell startup? you should only ever need to read from it till startup is completly done and in case of items or icons not found in it just dont display them till the user moves them to a new spot...

For mi it sometimes scramble it but arranges in the left side of the screen and scrambles the icons which are been already there.

ok still happens with the old style scramble when doing the command: 
kquitapp5 plasmashell && kstart5 plasmashell

seeing this in the log output if it helps:
file:///usr/lib/qt/qml/org/kde/plasma/private/containmentlayoutmanager/BasicAppletContainer.qml:144: TypeError: Cannot read property 'width' of null
org.kde.plasma.containmentlayoutmanager: Error: cannot change the containment to AppletsLayout
Trying to use rootObject before initialization is completed, whilst using setInitializationDelayed. Forcing completion

wish someone wouldve actually worked with me or anyone who has this issue and can reproduce it effortlessly. i wouldve been happy to test out any new development version of plasmashell. plasma is by far the best DE there is but issues like this make it impossible to recommend.
can we  use this ticket or do i have to open it again with the exact same description?

We can use this one; it's already re-opened.

"why is it so hard to remove any logik that touches that desktop-appletrc file during plasmashell startup? "
I think I can. It's the old topic of systemd. It's water under the bridge. Some 15 years ago, people wanted to enhance the user experience by shortening the startup sequence, and therefore started things in parallel. I never followed the gory details, since I am the old-fashioned style person, and would have preferred the slow, and clean, start. AFAIK, systemd took over many items, including login, and spawning independent items in parallel. I THINK, with a totally clean sequential startup, no other process would interfere - or could interfere -  in desktop applet layout. 
This is why I thought, the semaphore-like wrap around the startup, as proposed recently, could solve the case by isolating the desktop rendering, protecting the layout.

[If you look around, you'll find some other startup-bugs, including some affecting me, that could be attributed to parallelisms introduced by systemd; leading to RANDOM - that is not always or even rarely occurring - faulty behaviour. Systemd introduced a clever though not fully deterministic startup behaviour. I am willing to bet that after taking out systemd and revert to the old style rc-startup system - which is not possible, so that this is hypothetical - all these problems would be gone. With a slow, though fully sequential strictly one-task-at-a-time start sequence, race conditions are clearly avoided whatever the lengths of the steps. Boringly long, I agree.]

the point was that nothing should ever write to said file ever unless triggerd by a user-action (aka creating a new icon or moving one)
parallel or not it doesnt matter. Also systemd cannot be blamed for this all the major distros use it and they all manage to not f*** with user settings during startup process. plasma is the only one where this happens.

(In reply to Uwe Dippel from comment #36)
> "why is it so hard to remove any logik that touches that desktop-appletrc
> file during plasmashell startup? "
> I think I can. It's the old topic of systemd. It's water under the bridge.
> Some 15 years ago, people wanted to enhance the user experience by
> shortening the startup sequence, and therefore started things in parallel. I
> never followed the gory details, since I am the old-fashioned style person,
> and would have preferred the slow, and clean, start. AFAIK, systemd took
> over many items, including login, and spawning independent items in
> parallel. I THINK, with a totally clean sequential startup, no other process
> would interfere - or could interfere -  in desktop applet layout. 
> This is why I thought, the semaphore-like wrap around the startup, as
> proposed recently, could solve the case by isolating the desktop rendering,
> protecting the layout.
> 
> [If you look around, you'll find some other startup-bugs, including some
> affecting me, that could be attributed to parallelisms introduced by
> systemd; leading to RANDOM - that is not always or even rarely occurring -
> faulty behaviour. Systemd introduced a clever though not fully deterministic
> startup behaviour. I am willing to bet that after taking out systemd and
> revert to the old style rc-startup system - which is not possible, so that
> this is hypothetical - all these problems would be gone. With a slow, though
> fully sequential strictly one-task-at-a-time start sequence, race conditions
> are clearly avoided whatever the lengths of the steps. Boringly long, I
> agree.]

I'm 'afraid' I can confirm it's not systemd related, no. Gentoo user here, and although I've used systemd in the past, this particular laptop hasn't ever seen it. Gentoo has profiles which basically define the base set-up, ( https://wiki.gentoo.org/wiki/Profile_(Portage) ), and this laptop has always been on the OpenRC based "desktop/plasma (stable)" profile, rather than the systemd based "desktop/plasma/systemd (stable)" profile (or any of the other many options), so there's literally never been anything systemd related to get in the way.

OpenRC does also support launching startup daemons in parallel via an rc_parallel option in /etc/rc.conf but for me, this too has always been disabled so we can assume this isn't causing problems either.

Besides, Plasma starts after X which I believe waits for its own dependencies to fire up anyway, even with a parallel boot, so by the time Plasma kicks in there should be very few daemons still initiating. Things like WiFi connections which need to wait for remote services might not be quite there yet, but probably nothing related to graphics at all.

bump:
plasma 5.26.4, 2 month after the latest claum it would be fixed this is still happening alot on fresh kde installs, how can i  get the devs that worked on 
https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1150 and
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2240
to take a look at this issue again? it is rly rly annoying and an absolute no-go. As was pointed out it has nothing to do with systemd or anything happening before plasmashell startup. it happens even when plasmashell is started manually.

You convinced my about the systemd thingy. While I still see strange things coming up at boot, if this one can be reproduced with a start of plasmashell, it is a 'stand-alone' problem. And the Plasma people should look into it. (In case there is actually anybody left dealing with it. If not, inform us, and set it to WON'T FIX.)

Please check again in Plasma 5.27 which will be released in 6 days. More work was done for this issue in that release.

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

(In reply to Bug Janitor Service from comment #42)
> Dear Bug Submitter,
> 
> This bug has been in NEEDSINFO status with no change for at least
> 15 days. Please provide the requested information as soon as
> possible and set the bug status as REPORTED. Due to regular bug
> tracker maintenance, if the bug is still in NEEDSINFO status with
> no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
> due to lack of needed information.
> 
> For more information about our bug triaging procedures please read the
> wiki located here:
> https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging
> 
> If you have already provided the requested information, please
> mark the bug as REPORTED so that the KDE team knows that the bug is
> ready to be confirmed.
> 
> Thank you for helping us make KDE software even better for everyone!

As soon as 5.27 enters the stable branch on Gentoo, I'll update and test. Unfortunately need this machine to remain as stable as possible and can't risk pulling a whole DE from testing.

Nate, could you perhaps link to the main changelogs that we're hoping fix this?

Unfortunately there are too many changes to list. Plasma 5.27 fundamentally changes how desktops are bound to screens, and how icons are bound to desktops. The work can't really be selectively backported to 5.26 for testing purposes.

5.27 still isn't in stable yet on Gentoo, so I haven't been able to test myself, BUT something just occurred to me and I'm wondering if this is the same for all of us...

This particular laptop has 8gb RAM and a 512mb swap. It's getting old now but at the time of configuring it, 8gb seemed plentiful and in my ignorance I didn't think I'd need to set much of a swap up. These days with Plasma being quite memory hungry in general, and the likes of Virtualbox guests eating away at remaining resources, I'm hitting that 8gb capacity frustratingly often, and spilling over into swap.

What I'm now thinking, is that with so little swap space and so much memory in use, when I close the lid and trigger hibernation, there isn't enough swap for all in-memory data to dump to and perhaps that's why icon placements are getting lost? If on lid-open the system comes back out of hibernation, tries to restore whatever in-memory variables the desktop icons use, and finds that those variables aren't in the swap file so just regenerates them as empties then this would totally explain the skewed locations!

Does this sound familiar to others experiencing this issue? I'll resize my partitions as soon as I get chance and confirm if that, or indeed the 5.27 changes do fix this for me, but in the meantime if everybody could just compare their memory and swap capacities, we might find that there isn't anybody here who actually has enough swap to properly hibernate into. Would explain why this has been a problem for so many years, only affecting some but not all devices.

Unfortunately we've discovered that icon positioning is in largely the same boat as multiscreen positioning prior to Plasma 5.27: it's sort of fundamentally broken by design and requires a re-write to prioritize robustness and simplicity of design. So until that gets done (probably for Plasma 6.0) it's likely that this stuff will keep happening. :/ There are many many causes.

Instead of adding comments to this or any other existing bug report, it would be very helpful if, anytime the issue happens, people can do a bit of self troubleshooting to see if they can figure out the specific trigger that causes the issue. For example:
- Plugging in/unplugging/turning on/turning off screens
- Changing screen arrangement
- Rotating a screen
- Switching activities
- Creating or removing activities

If you could find the specific trigger that causes the issue, it would really help. After that, please submit a *new* bug report for the issue.

Thanks a lot everyone!

"He who laughs last, laughs best" goes the saying.
After years of fiddling with this, and an uncounted number of posts by, among others, Nick, the archives would reveal that this flaw was exposed earlier a number of times. Just read this: https://bugs.kde.org/show_bug.cgi?id=360478#c239
"... 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."
I was berated for my words, then. 

In earlier posts - my excuses for repeating myself - I had repeatedly tried my very best to explain what the conceptual design flaw was, in Plasma 5. My bad, I had not been able to express myself in words easier comprehensible, it seems. 

My thanks to you, Nate, without any irony, for your patience, and for Nick for updating his software tirelessly, only to find that it still didn't work. And still without irony, I do by now see some people lingering around around these problems as acquaintances. Should we ever have the occasion to meet up, I gladly buy you guys a drink!

Thanks a bunch for the time spent together! And my apologies should I have offended anyone in here ever!

Take care!

Yes, you were right. We'll try to build a simpler, more comprehensible, and more robust system for Plasma 6.

And please, do it quickly! With the most recent modifications, my way out of this problem, described several times in this and the previous threads, my fail-safe remedy, the PlasmaConfigSaver, was broken. Now calling it up results in a freeze, with a black unresponsive screen with just the mouse cursor, reproduceably.

(In reply to Uwe Dippel from comment #51)
> And please, do it quickly! With the most recent modifications, my way out of
> this problem, described several times in this and the previous threads, my
> fail-safe remedy, the PlasmaConfigSaver, was broken. Now calling it up
> results in a freeze, with a black unresponsive screen with just the mouse
> cursor, reproduceably.

The black, unresponsive screen with just mouse cursor on it is already 3-4 years old and it's the very reason, besides dancing icons, which made me quit KDE. Unfortunately, on the contrary of what you report, results were pretty much unpredictable: you shut down you machine and at the next reboot... BOOM!

At first, the only way out was backupping .kde folder and restoring it - just imagine the pain in the ass of backupping your DE every time you switch off your machine...

Eventually, the bug got so BIG that even restoring the old .kde folder still didn't sort a way out of the black screen; the problem (and pain) was that I couldn't exactly find what the heck was causing it.... it always came after initial (long) configurations and a small period of use (like one or two weeks). "Nice" to know this happened on Debian and some other distro I tried. I got so pissed off with this buttfuck that you know how the story went.

Too bad to know that somebody else is getting the same bad black screen :(

It's purely academically interesting, if at all, and only anecdotal. But here, I could at any moment solve any of these problems with the workaround of the Plasma Configuration Saver applet.  Just FYI. Not any longer.

Hi, I'm new to this thread, not to having this issue. This bit me infrequently between 2015 and 2019 on two separate Fedora workstations (each with 1 monitor), then it went away but after a recent upgrade from Plasma 5.26 to 5.27 it came back with a vengeance (single Fedora workstation, 2 screens). Rather than (after using KDE/Plasma for over a decade) changing to a different DE  (which I was very tempted to do but I guess Gnome 2 isn't around any more)  I decided to try some debugging first.

I've made an interactive shell script for myself with options to 1) create a backup of plasma-org.kde.plasma.desktop-appletsrc and to 2) quit plasmashell/restore appletsrc backup/restart plasmashell
( kquitapp5 plasmashell ; cp -v $backupfile $HOME/.config/plasma-org.kde.plasma.desktop-appletsrc ; kstart5 plasmashell & )

This allows me to quickly test out different screen configurations with the same appletsrc.

Notes on my current setup:
Left screen: Folder View, icons, panel on top of the screen
Right screen: Desktop View, no icons and panels etc. and set to primary display (can't remember why I did that)

Some provisional conclusions based on many tests:
-Turing the right screen off makes scrambling less frequent
-Setting panel to autohide (*) makes scrambling less frequent (50%)
-Setting right screen to Folder View usually moves my icons to the right screen (arranged in rows)

*) I've noticed during restart of plasmashell that sometimes icons are lined up correctly but get scrambled within a few hundred milliseconds. And I also noticed that their vertical space is squashed by a tiny factor when the panel is loaded in. I assumed this is so that the panel doesn't cover up icons so maybe the panel loading in may be a factor in this issue?

So far I haven't seen this issue happening when the right screen is off and panel is set to autohide but I want to test that some more...

(In reply to Pasha from comment #52)
> (In reply to Uwe Dippel from comment #51)
> > And please, do it quickly! With the most recent modifications, my way out of
> > this problem, described several times in this and the previous threads, my
> > fail-safe remedy, the PlasmaConfigSaver, was broken. Now calling it up
> > results in a freeze, with a black unresponsive screen with just the mouse
> > cursor, reproduceably.
> 
> The black, unresponsive screen with just mouse cursor on it is already 3-4
> years old and it's the very reason, besides dancing icons, which made me
> quit KDE. Unfortunately, on the contrary of what you report, results were
> pretty much unpredictable: you shut down you machine and at the next
> reboot... BOOM!
> 
> At first, the only way out was backupping .kde folder and restoring it -
> just imagine the pain in the ass of backupping your DE every time you switch
> off your machine...
> 
> Eventually, the bug got so BIG that even restoring the old .kde folder still
> didn't sort a way out of the black screen; the problem (and pain) was that I
> couldn't exactly find what the heck was causing it.... it always came after
> initial (long) configurations and a small period of use (like one or two
> weeks). "Nice" to know this happened on Debian and some other distro I
> tried. I got so pissed off with this buttfuck that you know how the story
> went.
> 
> Too bad to know that somebody else is getting the same bad black screen :(

Not convinced the black screen issues are related to this at all and should probably be a separate discussion, but in my experience black screens tend to be related to video drivers and just recompiling those against your current kernel usually resolves.

I better had not written anything; didn't want to re-enliven the discussion. 
My intention was rather to point to a problem directly related with the underlying bug; and this is one. My video and screen have been rock solid for years. Though I can 100% reproduce this black screen with mouse pointer only by clicking any configuration stored in the Plasma Configuration Saver. And since this one doesn't work on the hardware level, but with KDE-confirmation files, it is damn sure that it affects KDE configuration (crash KDE?), and has nothing whatsoever to make with video drivers.

(In reply to shadowfire+web from comment #54)
> Hi, I'm new to this thread, not to having this issue. This bit me
> infrequently between 2015 and 2019 on two separate Fedora workstations (each
> with 1 monitor), then it went away but after a recent upgrade from Plasma
> 5.26 to 5.27 it came back with a vengeance (single Fedora workstation, 2
> screens). Rather than (after using KDE/Plasma for over a decade) changing to
> a different DE  (which I was very tempted to do but I guess Gnome 2 isn't
> around any more)  I decided to try some debugging first.
> 
> I've made an interactive shell script for myself with options to 1) create a
> backup of plasma-org.kde.plasma.desktop-appletsrc and to 2) quit
> plasmashell/restore appletsrc backup/restart plasmashell
> ( kquitapp5 plasmashell ; cp -v $backupfile
> $HOME/.config/plasma-org.kde.plasma.desktop-appletsrc ; kstart5 plasmashell
> & )
> 
> This allows me to quickly test out different screen configurations with the
> same appletsrc.
> 
> Notes on my current setup:
> Left screen: Folder View, icons, panel on top of the screen
> Right screen: Desktop View, no icons and panels etc. and set to primary
> display (can't remember why I did that)
> 
> Some provisional conclusions based on many tests:
> -Turing the right screen off makes scrambling less frequent
> -Setting panel to autohide (*) makes scrambling less frequent (50%)
> -Setting right screen to Folder View usually moves my icons to the right
> screen (arranged in rows)
> 
> *) I've noticed during restart of plasmashell that sometimes icons are lined
> up correctly but get scrambled within a few hundred milliseconds. And I also
> noticed that their vertical space is squashed by a tiny factor when the
> panel is loaded in. I assumed this is so that the panel doesn't cover up
> icons so maybe the panel loading in may be a factor in this issue?
> 
> So far I haven't seen this issue happening when the right screen is off and
> panel is set to autohide but I want to test that some more...

I didn't realise you could set one screen to be Folder view and another to be Desktop view actually. I'd always assumed the desktop settings were global, not per screen. Unsure why I'd have concluded that mind.

Reading your post, I wondered if setting the primary screen to Desktop view would stop the icons attempting to move back to it when the secondary screen switches off, and hoped this would in turn prevent scrambling - but apparently not. If I leave my secondary screen as a Folder view with the icons arranged, and switch my primary to Desktop view, rebooting / closing the lid still scrambles everything like before.

> Not convinced the black screen issues are related to this at all and should
> probably be a separate discussion, but in my experience black screens tend
> to be related to video drivers and just recompiling those against your
> current kernel usually resolves.

I think I had that issue years ago as well (not now) and if I remember correctly in my case it was caused by an application in Autostart holding up the desktop loading startup process... (owncloud-client if I remember correctly)

(In reply to shadowfire+web from comment #54)
> Hi, I'm new to this thread, not to having this issue. This bit me
> infrequently between 2015 and 2019 on two separate Fedora workstations (each
> with 1 monitor), then it went away but after a recent upgrade from Plasma
> 5.26 to 5.27 it came back with a vengeance (single Fedora workstation, 2
> screens). Rather than (after using KDE/Plasma for over a decade) changing to
> a different DE  (which I was very tempted to do but I guess Gnome 2 isn't
> around any more)  I decided to try some debugging first.
> 
> I've made an interactive shell script for myself with options to 1) create a
> backup of plasma-org.kde.plasma.desktop-appletsrc and to 2) quit
> plasmashell/restore appletsrc backup/restart plasmashell
> ( kquitapp5 plasmashell ; cp -v $backupfile
> $HOME/.config/plasma-org.kde.plasma.desktop-appletsrc ; kstart5 plasmashell
> & )
> 
> This allows me to quickly test out different screen configurations with the
> same appletsrc.
> 
> Notes on my current setup:
> Left screen: Folder View, icons, panel on top of the screen
> Right screen: Desktop View, no icons and panels etc. and set to primary
> display (can't remember why I did that)
> 
> Some provisional conclusions based on many tests:
> -Turing the right screen off makes scrambling less frequent
> -Setting panel to autohide (*) makes scrambling less frequent (50%)
> -Setting right screen to Folder View usually moves my icons to the right
> screen (arranged in rows)
> 
> *) I've noticed during restart of plasmashell that sometimes icons are lined
> up correctly but get scrambled within a few hundred milliseconds. And I also
> noticed that their vertical space is squashed by a tiny factor when the
> panel is loaded in. I assumed this is so that the panel doesn't cover up
> icons so maybe the panel loading in may be a factor in this issue?
> 
> So far I haven't seen this issue happening when the right screen is off and
> panel is set to autohide but I want to test that some more...

I can now confirm that (on my system) setting the panel visibility to Auto Hide makes some difference; when I do multiple tries with my shellscript to reload my appletsrc backup and restart KDE:
Auto Hide disabled: icons are scrambled or messed up in some other way most of the time
Auto Hide enabled: 50% chance my icons completely disappear, 50% chance my icons line up correctly and (interestingly) if I then disable Auto Hide the icons stay line up correctly until the next restart. Also I haven't seen a scrambled icons state in this scenario.

Btw. my setup now is: left monitor: Primary / panel + icons / Folder view layout, right monitor: clean desktop (no panel, icons etc.) / Desktop view layout

And as mentioned I've noticed that when the panel is loaded in the icon area squashes slightly vertically (so the panel doesn't cover any icons that would be covered by the panel otherwise) and I think this is why disabling Auto Hide makes things behave differently.

> ....and I think this is why disabling Auto Hide makes things behave differently.

Oops, I meant: 
....and I think this is why enabling Auto Hide makes things behave differently.

This bug report is closed; please report new information or new manifestations of the issue with different root causes in new bug reports. Thanks.

(In reply to Nate Graham from comment #61)
> This bug report is closed; please report new information or new
> manifestations of the issue with different root causes in new bug reports.
> Thanks.

Shouldn't be closed, it isn't fixed. The number of separate bug reports that have had to be opened over the years for this because somebody keeps on closing it is ridiculous. Information is being lost in old reports that might actually be useful in the resolve!

The user-facing issue of desktop icons being re-arranged turns out to have multiple causes. It isn't feasible to track them all in a single bug report; that's not how issue tracking works. We need a separate bug report per discovered cause, so we can fix them individually. That's just the way issue tracking works, I'm afraid.

(In reply to Ric Grant from comment #62)
> (In reply to Nate Graham from comment #61)
> > This bug report is closed; please report new information or new
> > manifestations of the issue with different root causes in new bug reports.
> > Thanks.
> 
> Shouldn't be closed, it isn't fixed. The number of separate bug reports that
> have had to be opened over the years for this because somebody keeps on
> closing it is ridiculous. Information is being lost in old reports that
> might actually be useful in the resolve!

you're kind of right. 'Resolved' is kind of silly, sorry to say. If you wanted it closed, it could only go as 'Verified' and 'Won't fix'. 
"Desktop Icons sometimes get scrambled on plasmashell startup" is neither 'fixed' nor 'resolved'.

(In reply to Nate Graham from comment #63)
> The user-facing issue of desktop icons being re-arranged turns out to have
> multiple causes. It isn't feasible to track them all in a single bug report;
> that's not how issue tracking works. We need a separate bug report per
> discovered cause, so we can fix them individually. That's just the way issue
> tracking works, I'm afraid.

Ignoring previous tickets for now, this ticket as its own instance was originally opened May 2022 by William. His report was that when icons are placed on a desktop and plasmashell is restarted, said icons scramble. This issue, as a standalone bug, is still an issue.

If this ticket is closed somebody is just going to open another, reporting the same problem, and we're going to go through all of this again until it's again closed in this utterly ridiculous cycle.

I totally appreciate this isn't a simple fix but we can't just keep on closing these tickets and expecting the problem to be resolved somewhere else. Apart from anything else, opening multiple tickets for what is essentially the same problem just makes KDE as a whole appear buggier than it really is, in terms of number of but reports at least.

This, and all other related tickets, should be left unresolved, grouped, and cross referenced so that when related issues are resolved, developers can check whether these reports are also resolved and tick them off when that time comes, otherwise leaving them open for somebody to pick up at some point.

That's how bug tracking works.

Because we know this issue has multiple underlying root causes, we need to treat each one individually. We think it's fixed in Plasma 5.27.3 at this point. William hasn't told us otherwise; his last comment concerned Plasma 5.26.4 which we know was still buggy.

If you're saying that the issue still happens for you when you run `kquitapp5 plasmashell && kstart5 plasmashell`, we need to investigate that separately, because it could be (and probably is) happening for a totally different reason from why it was happening for William. It's totally possible that William will say, "hallelujah, it finally works for me in Plasma 5.27.3" and you'll say, "grr, no it doesn't, running `kquitapp5 plasmashell && kstart5 plasmashell` still breaks it for me!" All that means is that the same proximate causes (restarting plasmashell using kquitapp5 and kstart5) trigger different codepaths and you're hitting a buggy one. Hence, we need to fix that separately and we need a new bug report for it.

---

But if you want to know what will *actually* happen next, it's that developers will largely ignore the issue because they're completely overloaded with work and this issue is non-deterministic and impossible to reproduce at will. Eventually developers woh do get some time to work on this will throw out the old code because at this point we've learned that it's fundamentally flawed, and they write a new system that is architecturally better, like we recently did for KScreen. In the process they will fix the root causes of this issue but introduce new ones that were unanticipated or are the result of imperfect config migration, so the system will still feel buggy especially to existing users, just in different ways. Eventually those issues will be fixed one-at-a-time as well. After 2 or 3 years of bugfixing a system with a sane and comprehensible architecture, this part of the system will finally feel stable to new users and old users who have re-installed or figured out how to reset their configs.

Anything other than the above will require more development and QA resourcing than currently exist. If you would like to help make this better, I would encourage contributions with code, QA, bug triaging, or donations. Anything else isn't helpful, sorry. If you want to help, then help. Don't just tell us we're doing it wrong. What we need is more contributions from people who can help fix things.

(In reply to Ric Grant from comment #65)
> (In reply to Nate Graham from comment #63)
> > The user-facing issue of desktop icons being re-arranged turns out to have
> > multiple causes. It isn't feasible to track them all in a single bug report;
> > that's not how issue tracking works. We need a separate bug report per
> > discovered cause, so we can fix them individually. That's just the way issue
> > tracking works, I'm afraid.
> 
> Ignoring previous tickets for now, this ticket as its own instance was
> originally opened May 2022 by William. His report was that when icons are
> placed on a desktop and plasmashell is restarted, said icons scramble. This
> issue, as a standalone bug, is still an issue.
> 
> If this ticket is closed somebody is just going to open another, reporting
> the same problem, and we're going to go through all of this again until it's
> again closed in this utterly ridiculous cycle.
> 
> I totally appreciate this isn't a simple fix but we can't just keep on
> closing these tickets and expecting the problem to be resolved somewhere
> else. Apart from anything else, opening multiple tickets for what is
> essentially the same problem just makes KDE as a whole appear buggier than
> it really is, in terms of number of but reports at least.
> 
> This, and all other related tickets, should be left unresolved, grouped, and
> cross referenced so that when related issues are resolved, developers can
> check whether these reports are also resolved and tick them off when that
> time comes, otherwise leaving them open for somebody to pick up at some
> point.
> 
> That's how bug tracking works.

Not having a reputation system, I can only write 'Thumbs up!'.

It would really be a pity, if this in principle great project not only had a quality controller who knows nilch about quality control, but also a bug reporting system where responsables would understand only little about bug reporting. 

Having been in this business for 25+ years, if I find a bug, I check the list of bugs. If my observation was 'solved' in version x.y.z some two years ago, I'd assume another bug. And file a report. Instead, a 'Won't fix' would tell me to stop, live with this bug, work around it, buy a MS licence, or whatnot. Until it get's 'closed' and 'resolved'. Then I'd check for x.y.z; and I'd know about an eventual upgrade. 

One COULD even create a meta-report, like "Any kind of inconsistent icon position, be it at startup, restart, monitor change, etc." And mark it as "verified" "Won't fix" and an explanation. And relate all existing, different bugs reports there.

(In reply to Uwe Dippel from comment #67)
> One COULD even create a meta-report, like "Any kind of inconsistent icon
> position, be it at startup, restart, monitor change, etc." And mark it as
> "verified" "Won't fix" and an explanation. And relate all existing,
> different bugs reports there.
Feel free to do so. That would be a much more productive use of time than insulting people or the project as a whole is.

Changing status back to RESOLVED from VERIFIED because you haven't actually verified the fix, Uwe. As far as we know, it is resolved, but we need William to verify, since this bug was about his specific issue.

(In reply to Nate Graham from comment #66)
> Because we know this issue has multiple underlying root causes, we need to
> treat each one individually. We think it's fixed in Plasma 5.27.3 at this
> point. William hasn't told us otherwise; his last comment concerned Plasma
> 5.26.4 which we know was still buggy.
> 
> If you're saying that the issue still happens for you when you run
> `kquitapp5 plasmashell && kstart5 plasmashell`, we need to investigate that
> separately, because it could be (and probably is) happening for a totally
> different reason from why it was happening for William. It's totally
> possible that William will say, "hallelujah, it finally works for me in
> Plasma 5.27.3" and you'll say, "grr, no it doesn't, running `kquitapp5
> plasmashell && kstart5 plasmashell` still breaks it for me!" All that means
> is that the same proximate causes (restarting plasmashell using kquitapp5
> and kstart5) trigger different codepaths and you're hitting a buggy one.
> Hence, we need to fix that separately and we need a new bug report for it.
> 
> ---
> 
> But if you want to know what will *actually* happen next, it's that
> developers will largely ignore the issue because they're completely
> overloaded with work and this issue is non-deterministic and impossible to
> reproduce at will. Eventually developers woh do get some time to work on
> this will throw out the old code because at this point we've learned that
> it's fundamentally flawed, and they write a new system that is
> architecturally better, like we recently did for KScreen. In the process
> they will fix the root causes of this issue but introduce new ones that were
> unanticipated or are the result of imperfect config migration, so the system
> will still feel buggy especially to existing users, just in different ways.
> Eventually those issues will be fixed one-at-a-time as well. After 2 or 3
> years of bugfixing a system with a sane and comprehensible architecture,
> this part of the system will finally feel stable to new users and old users
> who have re-installed or figured out how to reset their configs.
> 
> Anything other than the above will require more development and QA
> resourcing than currently exist. If you would like to help make this better,
> I would encourage contributions with code, QA, bug triaging, or donations.
> Anything else isn't helpful, sorry. If you want to help, then help. Don't
> just tell us we're doing it wrong. What we need is more contributions from
> people who can help fix things.

Yep. My coding isn't current, alas. I have offered help multiple times, though not on the level of code.

Please stop changing the status to VERIFIED despite not verifying the fix. I'd like William to do that, since he's the one who reported this issue.

(In reply to Nate Graham from comment #70)
> Please stop changing the status to VERIFIED despite not verifying the fix.
> I'd like William to do that, since he's the one who reported this issue.

Sry i didnt keep up with what was happening in this isssue and i only recently got the 5-27 update in manjaro stable.

But i am happy to report now that it doesnt happen anymore for me. i removed my "read-only" workaround script and used the command "kquitapp5 plasmashell && kstart5 plasmashell" at least 50 times in a row, which previously would always result in some form of icon scramble, but this time it did not. Good job to whatever was done in the end that fixed it. 5.27 seems like a great release!

PS: manjaro skipped the early point releases and went straight to plasma 5.27.3.

(In reply to William from comment #71)
> (In reply to Nate Graham from comment #70)
> > Please stop changing the status to VERIFIED despite not verifying the fix.
> > I'd like William to do that, since he's the one who reported this issue.
> 
> Sry i didnt keep up with what was happening in this isssue and i only
> recently got the 5-27 update in manjaro stable.
> 
> But i am happy to report now that it doesnt happen anymore for me. i removed
> my "read-only" workaround script and used the command "kquitapp5 plasmashell
> && kstart5 plasmashell" at least 50 times in a row, which previously would
> always result in some form of icon scramble, but this time it did not. Good
> job to whatever was done in the end that fixed it. 5.27 seems like a great
> release!
> 
> PS: manjaro skipped the early point releases and went straight to plasma
> 5.27.3.

This is great news. Looking forward now to 5.27 hitting stable in Gentoo.

Apologies, Nate, for my comment #62. I'd interpreted your comment #46 as meaning this hadn't been fixed after all but it sounds like I was wrong there. It's frustrating that this still isn't available in the stable branch for me yet and I can't test first hand, but admittedly I probably shouldn't have jumped the gun on that.

Excellent news!

So for everyone else who is still experiencing the same *symptoms* of icons moving around, this confirms my suspicions that the root cause is something else, so allow me to repeat my request for new bug reports. :) We'll need individual bug reports to investigate individual root causes. Thanks everyone!

(In reply to Nate Graham from comment #73)
> So for everyone else who is still experiencing the same *symptoms* of icons
> moving around, this confirms my suspicions that the root cause is something
> else, so allow me to repeat my request for new bug reports. :) We'll need
> individual bug reports to investigate individual root causes. Thanks
> everyone!

Today I upgraded from 5.27.1 to 5.27.4 and it looks like I still have (partially) scrambled  icons after startup when I have the panel set to Always Visible (and my second display enabled), but when the panel is set to Auto Hide it seems to be fixed. (Although I will test that some more in the next days since I've only booted my computer a few times today.)

That sounds like Bug 458007.

(In reply to Nate Graham from comment #75)
> That sounds like Bug 458007.

Well, yeah I noticed that happening as well but my icons were also scrambled semi-randomly after the panel loaded so I initially thought it could be related some how... 

But anyway, now a couple of days and reboots later and the scrambling issue seems to have disappeared a day or so after my upgrade. (Not sure why it was still an issue right after the upgrade, maybe my configuration needed to be refreshed or something (?))

So it seems to be fixed here as well, I'm very happy with that :) Thanks very much!