SUMMARY *** Everything is already explained here: https://bugs.kde.org/show_bug.cgi?id=354802 except that the this has nothing to do with resolution changes, so 5.24.5 did not fix it. *** STEPS TO REPRODUCE 1. put icons on desktop 2. kquitapp5 plasmashell && kstart5 plasmashell OBSERVED RESULT icons switch position, seemingly random with some sort of order to it so the same layout of icons mostly results in teh same scamble EXPECTED RESULT icons stay where they were SOFTWARE/OS VERSIONS Betriebssystem: Manjaro Linux KDE-Plasma-Version: 5.24.5 KDE-Frameworks-Version: 5.93.0 Qt-Version: 5.15.3 Kernel-Version: 5.17.6-1-MANJARO (64-bit) Grafik-Plattform: X11 ADDITIONAL INFORMATION This has nothing to do with resolutions, multimonitors or variable refresh rates or what not. Happens on logout/login or reboot aswell.
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!
The only thing I can say is that during 4 months nothing happened but ....... for 10 days at starting my desktop icon were scrambled as usually. Nothing since. Système d'exploitation : Mageia 8 Version de KDE Plasma : 5.20.4 Version de KDE Frameworks : 5.76.0 Version de Qt : 5.15.2 Version de noyau : 5.19.7-desktop-1.mga8 Type de système d'exploitation : 64-bit Processeurs : 4 × Intel® Core™ i5-6440HQ CPU @ 2.60GHz Mémoire : 15,5 Gio de mémoire vive Processeur graphique : Mesa Intel® HD Graphics 530
You're using an ancient version of Plasma that doesn't contain the fix.
(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.