Every now & then my desktop icons on the Plasma desktop are scrambled to some sheme I never set ! Usually I lock the widgets but that doesnt help. Every 20 reboots or so suddenly after restart all icon positions are scrambled to for example the left side of the screen. The bad thing is I cant reproduce the effect but it usually hits me once a month... Unfortunately there is no option to save icon positions as I knew from old windows xp times. The "icon-bug" was a well knows effect in winxp too.. ; I use Manjaro 15.09 Bellatrix with KDE 5.4.2 but the effect was there some month ago with older releases.
icons on desktop as in the folder view? or applets? if you're unsure please post a screenshot
Created attachment 95355 [details] Folder view of Desktop Hi David...yes in Folder viwe as seen in the screenshot. Here they are as they should.. thanks !
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 set the bug status 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!
What info is needed ? It's indeed an old bug but it hit mee some weeks ago again with latest KDE version on Manjaro - rolling release. Right now I have: Kernel: 4.14.71-1-MANJARO x86_64 bits: 64 Desktop: KDE Plasma 5.13.5 Distro: Manjaro Linux Can't reproduce but it was on a reboot that all Icons lost theire position and have been placed on the left side of the desktop. Had to rearrange them one by one. Still missing a feature that saves and restores the icons. Even a hint where those settings ins the profile could be found. Regards, Michael
I've changed this to Reported.
*** Bug 360212 has been marked as a duplicate of this bug. ***
A have been observing this bug on multiple machines for a few years now. I have not found a reliable way to reproduce it. However, what I have learned so far: A lot less likely to happen if the Desktop configuration data (i.e. the home folder) is located on an SSD. Machines with spinning drives are affected much more frequently. Upgrading from openSUSE Leap 42.2 (Plasma Framework 5.27.0, Plasma Desktop/Workspace 5.8.3) to openSUSE Leap 42.3 (Plasma Framework 5.32.0, Plasma Desktop/Workspace 5.8.7) reduced the likelihood of triggering this bug by at least 50%, but it's still there. I have yet to migrate most machines to openSUSE Leap 15.0, so I do not have any data on it (yet). Interestingly, I have not seen this happening in VirtualBox VMs - just in case someone is trying it in there ... The graphics card driver / manufacturer does not make a difference - it's hitting systems with Intel, Nvidia and AMD graphics equally. It's also not limited to reboots, though reboots trigger this more frequently - it can also happen on a normal logout (not followed by a reboot).
Hello everybody, coming from three years long 360212 which has just been marked duplicate of this bug two days ago. Ready to offer cooperation in experimenting what is needed to forward useful information to devs. My machine is debian sid running KDE (siduction.org), and I hope to someday get desktop icons that don't get messed up at almost any reboot. Thanks
I also have the issue. Linux/KDE Plasma: Kubuntu 18.04.1 KDE Plasma Version: 5.12.7 KDE Frameworks Version: 5.44.0 Qt Version: 5.9.5 This is VERY ANNOYING. The reason I use folder view is because I can arrange the folders in a reasonbale manner to organize things. What is the point of having folder view on desktop if you cannot arrange folders? Any file manger does the job far better. I hope that this long-lasting bug is taken more seriously.
Created attachment 116418 [details] Before: 4 clean rows of icons. After shutdown/restart... a total mess. I recently made a new test in order to see "to which extent" my Plasma 5.12.6 desktop would get disorganized. So I sorted desktop icons manually in 4 rows, all aligned to the left: row #1 with MP3 files (grey) ; row #2 with PDF files (red) ; row #3 with text files (white) ; row #4 with all other kinds of files. I shut down my PC for the night. On the following day at startup, here is what my desktop looked like... No need to say it's getting painful to find a given file I wish to open... And this bug hits almost every day!
In Bug 360212, file .config/plasma-org.kde.plasma.desktop-appletsrc what pointed out by some users as being the one storing icons position. Q1. Could KDE devs please confirm this is correct AND the only file storing information about files position on the desktop? Comment #12 (https://bugs.kde.org/show_bug.cgi?id=360212#c12) suggested that this file gets monitored to identify which process gets a read/write access (first logical step to identify the faulty process). Q2. Could KDE devs explain how users hit by this bug can set up this kind of monitoring on their PC? Which tool should be used for this? How to configure it? This is the only way to progress on the resolution of this very annoying bug. Users are willing to help as much as they can (as you can imagine), but KDE devs have to step in and give a hand...
I am also affected by this bug. In folder view, after a reboot or even after awakening from suspend mode all icons are sorted by name no matter what option was chosen in the icons tab of the preferences. As a side note, two screens of my multi screen environment are set to desktop mode, one (the laptop screen) is set to folder view. Only folder shows this unwanted behaviour. Linux/KDE Plasma: Kubuntu 18.04 KDE Plasma Version: 5.12.6 KDE Frameworks Version: 5.44.0 Qt Version: 5.9.5
Is this bug still addressed or are we on our own?
Is there a developer outside who has some insight into the icon placement ? The metioned position (.config/plasma-org.kde.plasma.desktop-appletsrc) seems not to be the only location of icon position information. If I change icon positions and load the file again to compare some data change but it doesn't seem to be data related to the icon I moved. At least I can't see the relation.
Related bug? https://bugs.kde.org/show_bug.cgi?id=360478
I know this bug since kubuntu 14.04. Only that it then appeared every month or so, but now, with kubuntu 18.04, practically every day. I have just migrated to 18.04 from 14.04. The bug is especially annoying if you switch-off your computer on a nightly basis (like I do). I suspect many kde devs never switch-off their machines, hence they would never see the bug. The apparent reason for the mixed-up desktop is that the file ~/.config/plasma-org.kde.plasma.desktop-appletsrc is modified directly after I log into my computer. I presume that some kde program wants to check this file for plausibility or correctness, and then messes it up. What I have done to alleviate my situation is to make a copy of the afore-mentioned file prior to switching off my computer, and then use it to restore the file, and restart the plasma shell when I notice that the desktop is messed up after login. I use this small script to make the restoration and restart: <code> ------------------- #!/bin/bash # # Created by LC on 2018-11-28 # # To alleviate 'messed-up desktop icons' bug (KDE Bugtracking System – Bug 354802) cd /home/lc/.config cp plasma-org.kde.plasma.desktop-appletsrc.saved plasma-org.kde.plasma.desktop-appletsrc killall plasmashell kstart plasmashell </code> --------------------- A very ugly temporary fix - but it works for me. Hope we can find the real cause of the problem.
I don't know about KDE devs, but I've debugged this issue a bit and I think I found the root. I've made 2 patches which fix issue for me: https://github.com/iDarkTemplar/dt-overlay-patches/blob/master/profiles/patches/kde-frameworks/kio/kde-bug-354802.patch https://github.com/iDarkTemplar/dt-overlay-patches/blob/master/profiles/patches/kde-plasma/plasma-desktop/kde-bug-354802.patch First patch is for kio (tested on kio-5.50.0) and second one is for plasma-desktop (tested on plasma-desktop-5.13.5, requires patch for kio). It looks like if kio worker reports only part of files in directory, positions of other items are reset since they're not present. Later it reports those additional files and they get default positions assigned. The fix I made is adding an option for kio class to delay reporting until it's finished reading whole directory and using this option for folder desktop view.
Hello Dark Templar, and thanks! I can report that your diagnosis is true, because, among the several icons, only some don't get repositioned, while all the rest do. Looks like this is the real way to go. Will your patches be merged upstream?
I've posted links to patches here for a few reasons. People may try using patches and check if it fixes issue for them too and use it if it does fix the issue. Or someone may even make better fixes. I did a few improvements since originally posting the links. I might post it to the KDE phabricator later, but KDE devs still can find patches here. And posting patches doesn't mean they would be merged into upstream KDE anyway. For example of such hanging patch you may see https://bugs.kde.org/show_bug.cgi?id=383202
@i.Dark_Templar Good work on the analysis!
Created attachment 116730 [details] Misplaced bottom panel and usage monitors
Created attachment 116731 [details] Misplaced icons and usage monitor
Created attachment 116732 [details] Original placement with corruption fixed manually
I have attached some screenshots and I can reproduce this bug in Fedora 29 KDE, had this bug long since I began using KDE some months ago... KDE Plasma Version: 4.14.3 KDE Frameworks Version: 5.52.0 KQt Version: 5.11.1 Kernel Version: 4.19.5-300.fc29.x86_64 Running Nvidia proprietary, this issue is very frequent for me and it is annoying :( Came from the forum (refer to my post for the detailed explanation of my situation): https://forum.kde.org/viewtopic.php?f=289&t=156210
Damon, lets not confuse this by talking about things other than desktop icons. @i.Dark_Templar There's a potential issue with that patch. If you change dir (such as from configure) we'll get a new completed event. Also I think we can do everything inside plasma-desktop, which skips the need for the buffering and merging https://phabricator.kde.org/P279 - same principle but uses the source model as a buffer before we we set as folder model's proxy. It still needs a fixup as it still has that same issue with handling a directory change.
(In reply to David Edmundson from comment #25) > Damon, lets not confuse this by talking about things other than desktop > icons. Sorry about that David, I did not notice the discussion about this being a potential issue with KIO and reading delays for the desktop files... Should I remove my attachments here and open a new bug with a description of my issue (which also includes plasmoids/widgets)? Is it possible to "split" certain comments and attachments as a separate bug? Sorry, but I am not familiar with Bugzilla or the bug handling policy/protocol at KDE, so I have to depend on suggestions from more experienced members like you.
(In reply to David Edmundson from comment #25) > @i.Dark_Templar > > There's a potential issue with that patch. > If you change dir (such as from configure) we'll get a new completed event. > > Also I think we can do everything inside plasma-desktop, which skips the > need for the buffering and merging > https://phabricator.kde.org/P279 - same principle but uses the source model > as a buffer before we we set as folder model's proxy. > > It still needs a fixup as it still has that same issue with handling a > directory change. I think in my patch it's a bit more obvious where data is buffered. I didn't test your patch and not sure if it'd actually work, but it looks like it might work. As for issue with changing directory, does folder view store positions configuration for different directory somewhere? It doesn't look that way to me. But if it's still desired to fix this potential issue, then 'started(const QUrl&)' signal from dir lister has to be processed too, and for my patch values from qset and qmap for that URL have to be removed, for your patch I think source model has to be reset to nullptr to enable buffering again.
Thanks(In reply to i.Dark_Templar from comment #27) > (In reply to David Edmundson from comment #25) > > @i.Dark_Templar > > > > There's a potential issue with that patch. > > If you change dir (such as from configure) we'll get a new completed event. > > > > Also I think we can do everything inside plasma-desktop, which skips the > > need for the buffering and merging > > https://phabricator.kde.org/P279 - same principle but uses the source model > > as a buffer before we we set as folder model's proxy. > > > > It still needs a fixup as it still has that same issue with handling a > > directory change. > > I think in my patch it's a bit more obvious where data is buffered. I didn't > test your patch and not sure if it'd actually work, but it looks like it > might work. > > As for issue with changing directory, does folder view store positions > configuration for different directory somewhere? It doesn't look that way to > me. But if it's still desired to fix this potential issue, then > 'started(const QUrl&)' signal from dir lister has to be processed too, and > for my patch values from qset and qmap for that URL have to be removed, for > your patch I think source model has to be reset to nullptr to enable > buffering again. (In reply to i.Dark_Templar from comment #19) > I've posted links to patches here for a few reasons. People may try using > patches and check if it fixes issue for them too and use it if it does fix > the issue. Or someone may even make better fixes. I did a few improvements > since originally posting the links. > > I might post it to the KDE phabricator later, but KDE devs still can find > patches here. And posting patches doesn't mean they would be merged into > upstream KDE anyway. For example of such hanging patch you may see > https://bugs.kde.org/show_bug.cgi?id=383202 Thanks a lot for the patch coz this bug has been troubling for months. Hope it will be merge soon. How could I apply the patch manually? Are there any instructions/documentations I could reference to?
(In reply to d0048 from comment #28) > Thanks a lot for the patch coz this bug has been troubling for months. Hope > it will be merge soon. How could I apply the patch manually? Are there any > instructions/documentations I could reference to? You have to rebuild corresponding packages from source with these patches applied. For me packages are named kde-frameworks/kio and kde-plasma/plasma-desktop. Depending on Linux distribution you're using package names and methods used to rebuild packages from sources with additional patches may vary, look for documentation of your Linux distribution.
(In reply to i.Dark_Templar from comment #29) > (In reply to d0048 from comment #28) > > Thanks a lot for the patch coz this bug has been troubling for months. Hope > > it will be merge soon. How could I apply the patch manually? Are there any > > instructions/documentations I could reference to? > > You have to rebuild corresponding packages from source with these patches > applied. For me packages are named kde-frameworks/kio and > kde-plasma/plasma-desktop. Depending on Linux distribution you're using > package names and methods used to rebuild packages from sources with > additional patches may vary, look for documentation of your Linux > distribution. Also big thanks for your valable effort! Who's in charge for the merge?
*** Bug 403297 has been marked as a duplicate of this bug. ***
I finally have time to work on this again, sorry for the long, frustrating delay. I won't be going with i.Dark_Templar's patch, but his investigation has been invaluable; thank you for figuring out the cause of the problem, that's half the battle. I'm working on a patch that refactors Positioner to deal with multiple insert transactions properly, rather than buffering the data at all, for better performance.
New patch: https://phabricator.kde.org/D18598
Git commit aaebb51077aef6c5a5b974a38958e23366e357f2 by Eike Hein. Committed on 30/01/2019 at 09:43. Pushed by hein into branch 'Plasma/5.12'. Defer initial positions apply until listing is complete Summary: This fixes the infamous "desktop positions partially scramble on reboot" bug that occurs when KDirLister completes listing in multiple model transactions. This also: * Disallows moves and drops while listing, for extra safety. * Cleans up wonky old defer-sometimes code that made little sense. * Removes a cache for lastRow() that was never actually used. Reviewers: #plasma, davidedmundson, chinmoyr Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D18598 M +1 -0 containments/desktop/package/contents/ui/FolderView.qml M +6 -0 containments/desktop/package/contents/ui/main.qml M +63 -30 containments/desktop/plugins/folder/positioner.cpp M +2 -1 containments/desktop/plugins/folder/positioner.h https://commits.kde.org/plasma-desktop/aaebb51077aef6c5a5b974a38958e23366e357f2
The fix is on the 5.12, 5.14, 5.15 and master branches and will hit all subsequent releases from any of them.
I'd like to share my gratitude with all people who took time to analyze this awful bug and develop a fix. Still requires to hit end-users of course and prove its efficiency, but that's already a big step forward, so thank you!
Thank you very much, Eike. I will wait for upstream package update to test.
:) Thanks everyone for their patience again, and especially i.Dark_Templar and David for doing the initial work.
Many cheers and kudos to i.Dark_Templar. Had it not been for what you've found, this issue could've remained unresolved for who knows how long, if not forever. I am on 5.15 as of this morning and did a small test of moving around a bunch of files and folders and removing some and everything held it's position after the subsequent reboot. It "may" be premature (I hope I'm wrong, but I'm something of a pessimist in general), but I think it can be said it's fixed. If I manage to get myself to add/delete/move more files and reboot several more times and it sticks, then I'll be even more confident the fix is for certain. Bravo for taking what i.Dark_Templar found and taking it the rest of the way.
*** Bug 402449 has been marked as a duplicate of this bug. ***
Kubuntu 19.04 After each reboot my icons on Desktop is scrambled. Arghh, I'm angry! "Icons Lock" doesn't help Screen resolution is 1920x1080 and last icon row is empty. Icons is scrambled. KDE 5.15 Qt 5.12 Nvidia GT 1060 (418 driver)
You can't reopen a bug without useful information. It needs screenshots of before and after, details about what monitors there are ~/.config/plasma-org.kde.plasma.desktop-appletsrc
Before reboot: https://hostingkartinok.com/show-image.php?id=7442c09559595ca3659c23bb51cec697 After reboot: https://hostingkartinok.com/show-image.php?id=9e3cdc7e48b25ff7d867151e92d55381
Please attach your ~/.config/plasma-org.kde.plasma.desktop-appletsrc file.
My plasma-org.kde.plasma.desktop-appletsrc https://pastebin.com/XeSUERjE
Thanks!
The icons are rearranged after every reboot. Kubuntu 18.04.2 desktop in folder view mode. The icons are application.desktop used to launch my applications. I attach .config/plasma-org.kde.plasma.desktop-appletsrc files that get changed by the system on logout/shutdown. The workaround I found is to login to console with CTRL-ALT-F2 restore manually the good .config/plasma-org.kde.plasma.desktop-appletsrc file and then login to kde plasma.
Created attachment 121463 [details] The original and working .config/plasma-org.kde.plasma.desktop-appletsrc
Created attachment 121464 [details] The modified .config/plasma-org.kde.plasma.desktop-appletsrc after reboot with icons rearranged
Which version are you using, Claudio?
Claudio uses 5.12.7, but this bug says it was fixed for 5.12.8. Keeping open because of comment #41 (which unfortunately lacks Plasma version information).
Christoph, what information do you need?
(In reply to Christoph Feck from comment #51) > Claudio uses 5.12.7, but this bug says it was fixed for 5.12.8. Keeping open > because of comment #41 (which unfortunately lacks Plasma version > information). Plasma 5.12.8 has just hit Kubuntu 18.04 end users via the official updates channel \o/
I'm not yet able to tell if this bug is solved with Plasma 5.12.8 or not... All I can observe is that: - icons seem to use more space (wider) than before. - moving icons to the bottom of the desktop (bottom right of the screen, close to the taskbar) is very imprecise. Icons end up "somewhere else" most of the time, but rarely where I intend to drop them. Very frustrating. Anyway, I'm curious about last section of file ~/.config/plasma-org.kde.plasma.desktop-appletsrc. It's named [ScreenMapping] and seem to contain two subsections: itemsOnDisabledScreens=[...] screenMapping=[...] I couldn't find any technical description of these sections (in case there is one available somewhere, please tell me so), but I'm surprised to see that some files are referenced in the 1st subsection ("itemsOnDisabledScreens="), while I never connected any other physical screen to my PC in the last few years... So what does "disabled screens" mean? Note: most of referenced files are no longer present on my desktop (i.e. already moved elsewhere or trashed). 2nd subsection ("screenMapping=") references a very long list of files stored in sub-sub-subfolders of my desktop. What for?... It also appears that none of these files are present on my desktop today. I'm tempted to manually remove them from file ~/.config/plasma-org.kde.plasma.desktop-appletsrc, but what would be the risk of doing so?...
(In reply to Valdo from comment #54) > Anyway, I'm curious about last section of file > ~/.config/plasma-org.kde.plasma.desktop-appletsrc. It's named > [ScreenMapping] and seem to contain two subsections: > itemsOnDisabledScreens=[...] > screenMapping=[...] > I'm tempted to manually remove them from file > ~/.config/plasma-org.kde.plasma.desktop-appletsrc, but what would be the > risk of doing so?... What I did since my previous comment: - moved all files and folders from my desktop to another location. It seemed to me that sections "itemsOnDisabledScreens=" and "screenMapping=" did not change (much). Note: the 2nd section was actually a 148,768 characters long line! For which usage?... I still don't know. - booted another GNU/Linux distro and emptied above Kubuntu sections so they looked like: [ScreenMapping] itemsOnDisabledScreens= screenMapping= - booted Kubuntu again and moved all my files and folders back to the desktop. 2nd section ("screenMapping=") got filled again with a list of files now present on my desktop (note: no more files from sub-sub-subfolders of my desktop). Desktop icons are now under my visual monitoring to see whether they get scrambled again or not in the coming times...
I confirm it is fixed in 5.12.8
Claudio, Qt or Plasma?
He means Plasma :)
(In reply to Claudio from comment #56) > I confirm it is fixed in 5.12.8 It looks like being solved for me as well (after 1 week). Note regarding my previous two comments: my Kubuntu is a former 14.04, later migrated to 16.04, then to 18.04. It could explain why my plasma-org.kde.plasma.desktop-appletsrc file contained some surprising data... (successfully cleaned up as I described)
>He means Plasma :) I have Plasma 5.15 and bug is still present
I applied Eike's patch from comment 33 on my version of plasma-desktop 5.12.7 on March 2019 and enjoyed a number of trouble-free months. Now automatic update to 5.12.8 took place, and the problem re-appeared. Albeit with wider, more unwieldy icons as described by Valdo in comment 54. Pity.
Any news? I'm nervous every reboot
Hi all! I upgraded my Kubuntu to 19.10 and... bug is over. KDE Plasma 5.16.5 Qt 5.12.4 Who use Kubuntu please check and confirm it.
Occurring on Kubuntu 19.10 with the backport for Plasma 5.17, widget positions move up on every restart, and desktop icons to the very right of the screen get pushed down one and to the very left of the screen.
*** Bug 411488 has been marked as a duplicate of this bug. ***
For people still experiencing this, can you mention your screen resolution?
For reference, one duplicate report (Bug 411488) involved a non-full-HD resolution of 1280x800
I use 12800x800 and Plasma 5.17.2 on Arch Linux.
Ops, 1280x800*
Dear KDE team, This bug persists. It occurs almost every day. I don't think it can be like that in a LTS?
I'll see if I can get some eyes on this.
It would be great, thank you :)
This get weirder - it randomizes the icons 5-6 times for the past few days but now it randomized them without restart. I was watching a movie and when I closed the movie player I realized the icons are messed up again. I tried to rearrange them (again...) but this doesnt work - when I drop an icon to the location I want it doesn't go there but in the middle of the screen. I recorded a video: https://youtu.be/TCQOBym1KRU This is ridiculous... LTS???
Sorry, the video is here: https://youtu.be/P0wg1e5ZIn8
See this double icon: https://youtu.be/Kon0Mnr1yJI This usually is a a harbinger of icon shuffle event but not every time.
I left HD Sentinel icon at the middle of the screen and I went to sleep and turned off my PC. When I wake up and turn my PC again, the icon is on another place. See the picture: https://i.imgur.com/vEbw5Cq.png Tis isn't something unusual. It happens every day... Is that so hard to fix a thing others was fixed decades ago?
Nick, I understand that you're frustrated. But none of the developers can reproduce the bug. If we could, it would have been fixed long ago. We are currently investigating. But I would request a bit of patience.
Nate, I really don't know how to reproduce it, but everywhere I installed KDE on friends computers there are such problems. On my brother's computer I installed Manjaro KDE and these problems are there. Tell me if I can test something and be of some help :)
(In reply to Nate Graham from comment #66) > For people still experiencing this, can you mention your screen resolution? 1920x1080. And there's another problem which I believe is part of this bug: if you put an icon in the lower or upper right corner (folder view), after reboot the desktop protracts itself becoming 2400-ish pixels in length, a slider appears at the bottom of the screen (right above the panel) and the icon that you put in the corner can be found by using the slider. In addition to the protracted desktop after reboot almost all icons in the left part are scrambled. What's weird is that if you use conky, it remains inside the 1920 sized desktop and if you use the slider to find your missing icons, when you reach the end, these icons appear under conky, so you have to disable conky and then move the icons to the left in order to make the slider disappear. And if you reboot, all this happens all over again.
I have been having this issue much more frequently in the last few months. Using Kubuntu 18.04, Plasma 5.12.9. Resolution 1920x1200. I am using desktop folder view. There is a panel on the left that I use as an application launcher. Icons are mostly to the right of the panel (still on the left side of the screen, top to bottom), there are about 20 of them. I also use desktop background pictures chosen randomly from a folder. When I restart, there are several screen refresh happening. With some of these, icons stay where they are supposed to be. But one of these causes icons to move to the right of the screen, in diagonal from top-right to bottom-middle. The icon movements are the same every time, it is not random. Icons end up moving about 80% of the time. I suspect some kind of race condition or something related to the speed of the refresh - adding to the refresh or startup load might help to reproduce it.
To clarify: when the icons do not end up moving, they still move briefly to the right of the screen during the various refresh, and then they move back to their normal position. So the issue seems to be a case of the icons not moving back after moving to the wrong position. I tried to move the panel to the right of the screen, or use a plain background color, but that didn't change anything.
Icons get shuffled every single day on my end. It's hard to believe the devs can't reproduce the problem...
(In reply to damien.kde from comment #81) > To clarify: when the icons do not end up moving, they still move briefly to > the right of the screen during the various refresh, and then they move back > to their normal position. So the issue seems to be a case of the icons not > moving back after moving to the wrong position. > I tried to move the panel to the right of the screen, or use a plain > background color, but that didn't change anything. IDK if you have discovered that yet but icons get shuffled EVEN IF they were locked in place to prevent their movement, lol
Just to say I have this problem every day. Every day I arrange my icons again and again. Yes you already know that but this time they are shuffled without a restart! I worked on my PC and when I looked at my desktop the icons are scrambled. I didn't restarted or change resolution. Look at them how they are shuffled and look at the double icon: https://i.imgur.com/wOi9zrd.png Just as reminder how arrange them every day: https://i.imgur.com/6iaKvlA.png When I tried to move the doubled icon it got blured, zoomed and the picture in it was misplaced: https://i.imgur.com/9KoTi4c.png When I drop it, it literally flied on another place on the upper right corner instead bellow cursor. Why the hell the system will shuffle and double my icons without any intervention? And one more thing - sometimes it happens only from turning off my display. I stopped all energy save functions (turn off monitor, etc.) because of this to no avail. The problem is still here...
I found something interesting that may be of use to devs to fix the problem. When I put my icons on the very upper left corner, the problem is gone completely! No more icon shuffle and double icons. https://i.imgur.com/7Ua0Xjx.png I tested it for 6 days and it's working great. If I position them one grid cell down, the problems come again. https://i.imgur.com/Chzc0aj.png For now I made a shortcut with no icon and no name and this do the trick but it's a dirty solution you will agree. This doesn't solve the problems with moving icons if they are positioned somewhere on the desktop. If I create a text file for example and put it on a random place on the desktop but not bellow the other icons on the left, this text file will float on different positions at different circumstances like restart but not always. I think these problems occured when the grid size has been fixed some time ago.
Oh no... Today I start my PC and: https://i.imgur.com/OiJ13rt.png https://i.imgur.com/B7v5hdh.png It's a new shuffle pattern. See where the invisible icon is. They were in this order: https://i.imgur.com/f9wVOwC.png
Nick, I'm going to give you a little heads-up/hint... Look at the top of all this when the issue was first reported. You've done your part on reporting its continued existence, but you have yet to attach your desktop-appletsrc file that David had mentioned multiple times in this thread. You'll see that a user had found the issue once https://bugs.kde.org/show_bug.cgi?id=354802#c19 and then 2 months later a dev took their results and went a different direction with it. The takeaway is that it's been a long-standing issue and it would do you well to take a look at the entire thread to see how things have transpired and what has been requested. I'd say that if a dev isn't responding to your various findings, you may very well be wasting your breath. You may just find that KDE just isn't for you in this regard if the icon order issue is bothering you this much, or that a bug continues to go unresolved. It can be equally rough for a dev that can't replicate the issue on their side, as it is for the user who can't get suggestions from devs that may aid the dev in the discovery of the location of the bug.
Thank you, I don't want give up on Plasma. Here's my plasma-org.kde.plasma.desktop-appletsrc: https://pastebin.com/7ipapX23
I reset the desktop layout a few days ago but today the icons are shuffled again: https://i.imgur.com/SkZIr35.png The empty space is the noname icon I created before.
I'm going back to KDE soon, are there any logs I could upload here after this bug occurs to help tracking the problem?
*** Bug 389705 has been marked as a duplicate of this bug. ***
*** Bug 392255 has been marked as a duplicate of this bug. ***
A workaround has been found in https://bugs.kde.org/show_bug.cgi?id=389705#c0. It looks like the position= line in ~/.config/plasma-org.kde.plasma.desktop-appletsrc is being changed inappropropriately.
And I'm very happy to confirm it's fortunately working great :)
It's ridiculous icons get scrambled even without restart. Sometimes just turning on the monitor and they are shuffled. Because I use this workaround: https://bugs.kde.org/show_bug.cgi?id=389705#c0 they get in order if I restart but the fact is they are scrambled just on monitor turn off...
(In reply to Nick Stefanov from comment #95) > It's ridiculous icons get scrambled even without restart. Sometimes just > turning on the monitor and they are shuffled. Because I use this workaround: > https://bugs.kde.org/show_bug.cgi?id=389705#c0 > they get in order if I restart but the fact is they are scrambled just on > monitor turn off... I think the best workaround would be to make the .config/plasma-org.kde.plasma.desktop-appletsrc that Nate mentioned to be read only. If you need to make any changes, make it editable, make the changes you want and then make it read only again. Thus the icons won't get scrambled.
Since a long time I thought everything is fine now... never got a problem with scrambled icons sincey years. But now suddenly after some weeks the problem reappeared. Still on Manjaro..latest version.. today I started the PC and even with Desktop icons positions locked they got scrambled again. Happened some weeks ago the first time after years.. now every some weeks.It's really annoying because I have a bunch of icons and it costs some time to rearrange. I dont know how long I will be using KDE ...soo many bugs that dont get solved in so many years. That once was a problem in windows and I used a Tool "Desktop OK" that allows saving and restoring complete Icon Layouts. Would be useful to have such a tool to sometimes do a save and restore in case of when it's happening again. But even that is missing. Maybe I will write a script saving "/home/user/.config/plasma-org.kde.plasma.desktop-appletsrc" and give it a try...again. Happy Easter...
I left them there: https://i.imgur.com/i4usz60.png I turned off the monitor and went to do some tasks for a while. When I returned and turned on the monitor I found them there: https://i.imgur.com/OqYJ0GW.png And this happens all the time. All powersavings are turned off, even the option for turning off monitor after certain amount of time. This is an unacceptable problem that no one is paying attention to. And it's present everywhere. My brother's PC is with Manjaro KDE and he experience pretty the same behaviour. There's no DE with such stupid and irritating problem but no one cares... May be you can start from the problem when an application changes the resolution and the icons get scrambled and such behavior isn't observed on another DEs. For example - if one start a game with a lower resolution, the icons get rearranged from this: https://i.imgur.com/J3p3u0g.png To this: https://i.imgur.com/ZDXrDeC.png or even this: https://i.imgur.com/jGMtzq1.png This is just unacceptable, it's ridiculous. Even a young DE like Cinnamon doesn't got scramble it's icons on a resolution change. Even Windows '95 :( I think it's the root of this problem. Let start from here - prevent icons moving on resolution change.
Hello Nick, in just some months this bug will "celebrate" its 5th "anniversary" and it's still around like dogshit on pavements: "unacceptable" has already become an understatement. After fighting over it in 2018 and uselessly offering my cooperation, I sadly catched there is not much interest in fixing it, so I switched to gnome3. But I am still reading this thread, in order to know if I will ever be able to use KDE again, it's always been my favourite. I can give you a hint: not all distros react the same way, I recently had some luck with debian sid and SolydK (pretty nice job distro, btw), so, if you're stubborn enough, your mileage might vary and you could find the sweet spot. This said, good luck, and let us know! Pasha
Thanks Pasha, I've being using Arch for over 10 years and I don't want to change my distro. I started with Ubuntu but Arch is way flexible, faster and convenient. I have installed may be over 200 Linux installations for my friends and their friends and I always install them Mint Cinnamon. I want to instal them KDe but with this problems I'm afraid they will blame Linux hence I decided to install them Cinnamon. We just want some bugs fixed for the best DE :(
hey, expirienced this Bug too. Do you use only one Screen/Activity like me? For me it doesn't happen all the time. sometimes the items stay after reboot (or logout/login) and sometimes they dont.- Just to clarify. you are using FolderView Desktop Layout? I tried this now (based on Comment 54, 55 by Valdo) and i think it helped: time will tell if the icons get rearranged again: open dolphin and go to your ./config folder to locate the file "plasma-org.kde.plasma.desktop-appletsrc" Then open a terminal and run kquitapp5 plasmashell your desktop should get black but the filemanger(dolphin) stays open. Then open the file mentioned above and scroll down till u find the Section [ScreenMapping] itemsOnDisabledScreens= screenMapping= for me there were lots of old names/files in those 2 lines (after the =) that got long deleted and were not present anywhere anymore. I dont know what these 2 lines are there for and what they do. its always good to make a backup before edits. So i deleted everything after the "=" signs so it looks like above and then run: kstart5 plasmashell i post this so others may try this at their own risk as i havent seen the icons rearranged after this but it didnt happen all the time anyways so i am not sure if it helped.. Maybe some dev can tell us what these lines are there for and why old long gone filenames end up in those lines...
Yes, I use only one Screen/Activity and FolderView Desktop Layout. I use this workaround: https://bugs.kde.org/show_bug.cgi?id=389705#c0 And it helps a lot but not always. Sometimes my additionaly created files are moving just on monitor tiurn off/turn on and the doesn't stay where I placed them. Sometimes, when a resolution change occurs for some reason, some of the icons get double right border and it's a harbinger of almost sure icon movement in the future. https://i.imgur.com/wOi9zrd.png When I try to move the doubled icon it get blured, zoomed and the picture in it was misplacedb but the two last are not obligate: https://i.imgur.com/9KoTi4c.png It's very strange... https://i.imgur.com/vEbw5Cq.png https://youtu.be/Kon0Mnr1yJI
Seems like there is a lot more going on than just the rearrangement bug that others and me are describing. Have you tried deleteing your icon-cache.kcache? Some reddit post said it helped but for me it didn't: https://www.reddit.com/r/kde/comments/fmd18x/at_reboot_my_kde_desktop_icons_are_fully_messed_up/
My icon cache is in RAM and is being deleted on every reboot :)
I beg the devs watch the following video: https://youtu.be/YhCz1nILuho My icons got scrambled WITHOUT restart (again). I decided to rearrange them and this is what happened. Changing the resolution solved this weird behaviour. I think this is very serious bug and it's time to receive a very high priority. There's something generally wrong with KDE, desktop icons and resolutions. After all, the desktop is the face of the DE and it's totally borked. I think this is a good start and it's the root of the problem: https://bugs.kde.org/show_bug.cgi?id=420903
Can we expect a fix of this bug any time soon?
Today first time since I made my patch and later switched to upstream patch, some issue happened on my system which lead to partial desktop settings reset. Not sure what caused it. I did a series of logouts and logins back to same user while debugging different issue, and after one of logins some settings were reset. Following settings were reset for me: desktop wallpaper desktop icons size all desktop icon positions Following settings were left intact: desktop panels configuration Since I don't use desktop widgets I have no idea if they'd be reset as well. I've tried doing a bit more of similar logouts and logins but was unable to reproduce it once more. OS: Gentoo Linux Session: X11 Plasma: 5.18.5 KDE Frameworks: 5.70.0 KDE Applications: 19.12.3 Qt: 5.14.2
These last months I regularly had the following problem on my Kubuntu 20.04 (upgraded from 19.10, from 19.04): the desktop icons get reset to the top of the screen, in alphabetical order, and the wallpaper gets reset to the 'Next' wallpaper. Remarkable was that this didn't happen on my 'test'-user, a user I made just to see if problems on my main user also happened there, and to try out color-schemes etc. I tried about anything to solve this bug: deleting the plasmarc, plasmashellrc and plasma-org.kde.plasma.desktop-appletsrc files in /home/user/.config, lock desktop icons, switch to 'restore previous session' instead of 'start with empty session', add [OSD] Enabled=true [PlasmaToolTips] Delay=0.7 to my plasmarc file (I copied this from my 'test' user), put my desktop icons away from the lower end of the screen. Nothing of that worked. Then I tried to change my wallpaper to the one I used on 'test': Autumn 5.5. And with that wallpaper I didn't have this problem (after trying ± 10 reboots/relogins). I thought it had to do something with the resolution of the wallpaper, but the wallpaper 'Kite', which has exactly the same resolution, did produce the bug after 2 or 3 tries. Then I started to think: maybe it's really about the color of the wallpaper, however outlandish this may be. So I made a monochrome blue wallpaper with color #000080. The fourth time I logged in again, icon position and wallpaper were reset. Then I tested a monochrome wallpaper with color #fefe7f, 'soft' yellow, and after 10 times there still was no reset of anything. Then I retried the blue wallpaper and already the second time: reset. Then I wanted to reproduce this on my 'test' user, but using the blue wallpaper, I didn't get any reset after dozens of reboots/relogins. Strange indeed. I tried to get my 'test' desktop as similar as possible to my usual desktop, but I can't get the icons to reset on my 'test' user. But now I don't seem to get any icons reset on my normal user either. What may have caused it (I'm not 100% sure) is that in Dolphin settings I disabled thumbnails for folders. But on my desktop I still got thumbnails for folders because this was enabled in the desktop settings. (Maybe there's some conflict there...) When I didn't get the bug after some tries, I re-enabled thumbnails for folders in Dolphin, but now the bug doesn't return (or seems not to). What didn't help was emptying the thumbnails cache. My impression is that there are all kinds of factors (some maybe hardware-related) that cause the plasmashell to sometimes get 'overloaded' and to reset icons and wallpaper. I have to add that I never got this problem on my Mageia KDE (which uses Plasma 5.15) and on my Manjaro KDE I did get this some time back, but not the latest month or so. OS: Kubuntu 20.04 Session: X11 Plasma: 5.18.5 KDE Frameworks: 5.68.0 Qt: 5.12.8 Dolphin version: 4:19.12.3-0ubuntu1 HP Laptop 17-ak0xx
I cheered too soon, when I used the 'EveningGlow' wallpaper, I immediately got an icons+wallpaper reset. This was with folder thubmnails enabled in Dolphin, but also when I disabled it, I got the bug back. But: when I disable folder thumbnails both in Dolphin and in the desktop settings, the bug seems gone. Maybe this can be connected to Valdo's remark in comment 54: "2nd subsection ("screenMapping=") references a very long list of files stored in sub-sub-subfolders of my desktop." I remarked this also when looking at the plasma-org.kde.plasma.desktop-appletsrc file. This may be the directorythumbnail plugin looking at those subfolders... I'm still not able to reproduce this on my 'test' user. The only reason I can invent is this: I have two folders (in fact: symlinks to folders on data partition) on my desktop with a lot of subfolders, but they are owned by 'myself' and not by 'test', so 'test' doesn't have full access to them. But now there's another problem: using 'EveningGlow' as wallpaper, after a few tries this setting to not show folder thumbnails gets reset, combined with a wallpaper and icons reset at the same time. I tried to totally disable thumbnails in the desktop settings, but eventually this also got reset. I then tried to totally disable thumbnails also in Dolphin, but again the desktop thumbnails settings got reset, not the Dolphin ones though. After a lot of trying I also got an icons reset using 'Autumn 5.5' as wallpaper, so it doesn't totally prevent the bug. I retried the experiment with my monochrome wallpapers, to see if I had just invented this thing about wallpaper color. I tried logout-login with the yellow wallpaper 15 times: no bug. I did the same thing with the blue wallpaper 10 times: also no bug. But then I thought: maybe it does make a difference whether you relogin or reboot. So I tried 7 reboots with the yellow wallpaper: no bug. But the first time I rebooted with the blue wallpaper: bug. And when I then did logout-login with the blue one the bug happened again after 4 or 5 tries. So I still think the color does make a difference. But given the fact that I never had this bug on my 'test' user, there has to be a relevant difference in settings somewhere, right? What didn't work in any case was removing [DesktopIcons] Size=48 from both .config/kdeglobals and .kde/share/config/kdeglobals Any other suggestions where the difference might be?
I obviously should have tested this earlier, but I removed the symlinks to the folders with many subfolders from my desktop and now it SEEMS to work, but with this bug that may be the most dangerous thing to say. When I put the symlinks back, the bug came back after some 7 tries or so. I still can't reproduce the bug on my 'test' user though, also when I changed the ownership of the symlinked folders to 'test'. But I guess the directorythumbnailer is just one of the factors that can push plasmashell 'over the edge', as the bug doesn't happen consistently. If only plasmashell would have a log file, but there doesn't seem to be one, or do I have to install some debug package?
if your wallpaper and icons and desktop widgets all get reset it sounds like plasmashel didnt start correctly at all which i think is a different bug and beliving it has to do with wallpaper colors or sizes is superstition. When it happens you can try to restart plasmashell and see if that way you get your old icon positions, wallpaper, etc back: kquitapp5 plasmashell; sleep 2s; kstart5 plasmashell If yes then this is not the original bug - only icon scrambles are happening right after login and wallpapers/widgets all stay same. and even after a plasmashell restart the icons are still wrong as the wrong positions are already safed to the plasma-org.kde.plasma.desktop-appletsrc file Btw: the icon-scramble only didnt happen to me for a month now after i added a metamode to my nvidia.conf screen section. i guess it is something to to with nvidia drivers like alot other bugs.
better command to restart plasmashell: plasmashell --replace
To get the bug back I put my symlinked folders back on my desktop and after some tries I indeed got a wallpaper+icons reset. I tried 'plasmashell --replace', this didn't make any difference to wallpaper or icons. So I've made a zip file with three folders: each with plasma-org.kde.plasma.desktop-appletsrc, plasmashellrc and plasmarc, plus screenshot in the two first. 'Before' is before the bug happens, 'after' is after the bug, and 'after2' is after I did 'plasmashell --replace'. In plasma-org.kde.plasma.desktop-appletsrc there are many differences, only one difference in plasmashellrc (don't know if significant), and no difference in plasmarc. Somehow something goes wrong of course, but does plasmashell really have no log file? How do developers know what goes wrong if something like this happens to them?
Created attachment 129682 [details] files and screenshot before and after bug
ok. weird thing with those changes is that after the bug happens your "plasma-org.kde.plasma.desktop-appletsrc" is missing the config for icon-positions. (a line that starts with "positions=". This was never the case for me. regarding logs i dont think any devs are interested in this 5year old bug ticket and it doesnt seem to affect any of them so they can not reproduce. you can try this since there is alot of stuff in those 2 lines for you, run: kquitapp5 plasmashell then edit 2 lines in your "plasma-org.kde.plasma.desktop-appletsrc" [ScreenMapping] itemsOnDisabledScreens= screenMapping= so there is nothing anymore after the "=". dont worry they will automatically refill with the current settings aslong as you dont change anything else. then run kstart5 plasmashell when starting plasmashell like this you get some output but i doubt it helps anyone with identifying the problem. another thing to try is the icon-cache delete.- apperently someone fixed it that way. But moving around folders and thinking it has an effect on this bug only confuses others - i very much doubt it changes anything and this bug just does not happen everytime/consistently
Created attachment 129685 [details] output of .xsession-errors from 2 sessions without bug and 1 with bug I found out about the (not very user-friendly) .xsession-errors file, and I've made three text files: 'session_nobug' and 'session_nobug2' with the output from two sessions with no bug occuring, and 'session_bug', with output from a session with bug. My guess about where the bug happens is in lines 188-9 of session_bug: org.kde.plasma: requesting config for "Mapweergave" without a containment! #"Mapweergave" = Folder View QObject::disconnect: Unexpected null parameter I don't know if this gets us closer to a solution, but at least I appear to be the first one in five years to post log files here.
i think there is plenty people here that are willing to help or provide any logs etc... it is simply no dev/capable person requesting anything and therefore we are left to try stuff and share... My point was only to not post out-of-the-blue assumtions about wallpaper colors or folder names etc.. <100 reboots without this error can still be a coincidence (in my expirence) so trying all the stuff and saying it helped is pretty hard - only logical thinking tells me some stuff is not worth trying (wallpaper colors/ folder names etc) but hey go ahead when you have the time - i posted what i did already and im a month in with no occurrence - but good luck with finding someone that can fix your specific issue.
Hello friends, just dropping a thought: if devs cannot easily reproduce this bug and therefore do not get interested in squashing it, one of us with an updated and terribly scrambling desktop could make up an OVA file out of his system in order for the devs to be able to consistently reproduce the bug! ...of course this would be useful only if a willing dev could be elicited...
Would be nice if someone else with similar problems to mine could confirm they have the following two lines in /home/user/.xsession-errors when the bug occurs: org.kde.plasma: requesting config for "Folder View" without a containment! QObject::disconnect: Unexpected null parameter # or translation of "Folder View" in the first line Then at least a tiny something would be reproducible. In another session with bug, I had that message again, so for the first time I think I have some hard evidence. My apologies for bothering you about wallpapers and thumbnailers, after some extra testing I can exclude both. My idea was simply that if this bug hasn't been fixed in five years, there might be something bizarre going on which nobody had had the idea to test.
I am probably the n-th guy having this problem. That's really ANNOYING. I can't reboot a single time without my desktop being totally disordered when showing up. This definitely need to get KDE devs' focus. Distribution: Arch Linux btw 5.75.5-arch1.1 Architecture: x86_64 Qt version: 5.15.0 KDE Plasma 5.19.2 (frameworks: 5.71.0)
Just had the bug hit me today after resuming my Manjaro System from standby. All Icons were moved to the top of the screen and resized to a bigger (default?) size. The Bug now exists for 5 years...at least.. KDE Plasma 5.18.5 on latest Manjaro rolling release, Kernel: 5.4.44-1-MANJARO x86_64. Last time I had the problem in April...thought it's gone but it isn't. Can some Dev point to ressources where the logic of saving and reading desktop icons is described ? Is there some documentation ? best regards, Mike
(In reply to toon.pepermans from comment #119) > Would be nice if someone else with similar problems to mine could confirm > they have the following two lines in /home/user/.xsession-errors when the > bug occurs: > > org.kde.plasma: requesting config for "Folder View" without a containment! > QObject::disconnect: Unexpected null parameter > # or translation of "Folder View" in the first line Nice finding Toon! I'm in a situation very close to yours (Kubuntu 20.04, and same behaviour: icons sorted at boot time (only once so far) - folders first, then files - and wallpaper reset as well) except that my Kubuntu install is a FRESH one (not an upgrade from 18.04). As a matter of fact, I can also find this set of lines in file .xsession-errors (3 "Plasma Shell startup completed" ago, meaning 3 days ago - I usually boot my PC only once a day - meaning in turn that it occurred on the exact day I faced this issue - July 17th): org.kde.plasma: requesting config for "Vue de dossier" without a containment! # "Vue de dossier" means "Folder View" QObject::disconnect: Unexpected null parameter QObject::disconnect: Unexpected null parameter (last line does appear twice in the log) Whether "our bug" (leaving evidences in .xsession-errors) is the same as the initial 354802 or not, I can't really tell... (the wallpaper reset is new!) Inputs from other users facing initial bug 354802 saying whether they find the same message in .xsession-errors or not would really help triage bugs. Thanks in advance folks.
(In reply to i.Dark_Templar from comment #107) > Following settings were reset for me: > desktop wallpaper > desktop icons size > all desktop icon positions > > Since I don't use desktop widgets I have no idea if they'd be reset as well. I didn't realize it at first, but when this bug hit me (still once only), the only widget I had on my desktop got removed. So it looks like widgets get reset as well.
(In reply to Valdo from comment #122) > (In reply to toon.pepermans from comment #119) > > Would be nice if someone else with similar problems to mine could confirm > > they have the following two lines in /home/user/.xsession-errors when the > > bug occurs: > > > > org.kde.plasma: requesting config for "Folder View" without a containment! > > QObject::disconnect: Unexpected null parameter > > # or translation of "Folder View" in the first line Second occurrence for me! Still at boot time. And again these lines logged in .xsession-errors: org.kde.plasma: requesting config for "Vue de dossier" without a containment! QObject::disconnect: Unexpected null parameter QObject::disconnect: Unexpected null parameter I hope this interesting hint can be investigated by devs at the end of summer time.
Any progress on this? I use this workaround: https://bugs.kde.org/show_bug.cgi?id=389705#c0 Today I decided to turn it off to see if there's any improvement. On the first restart my icons got scrambled again... I think it's time for someone to finally look at this please.
KDE Frameworks Version: 5.75 - the problem is still here.
Nick, I mentioned to you in comment #87 that you're basically wasting your time. Now in comment #127, I'm going to tell you that all you're doing is spamming to 31 people. Saying it exists in the most recent version is not helpful. I'll all but guarantee it's going to be in version 5.76 as well, and even later versions and I have no interest in getting a notification for that in particular. If it's that much of a bother to you and you don't want to continue using the workaround, I'll suggest again that you just move on to something else even though you said you don't want to in #88.
It's a seriuos (ridiculous) bug and it have to be fixed. It's the only DE in the world with this problem. Yeah, right - it's KDE.
I can completely understand Nick with this. It's been almost 5! years since the first message in this thread and the bug still hasn't been fixed. Seriously, that's ridiculous. If the devs are unable to fix this then maybe they should start from scratch or stop programming for good! By the way, this bug is the reason why I stopped using KDE already a while ago...
To reiterate: posting negativity makes people capable of fixing this issue less likely to do so rather than more, because dealing with you will seem like an unpleasant experience. Whining and complaining in pubic is thus counter-productive. Sorry to hit you with the hard truths, but that's just how it is. :) If you're desperate for this to be fixed, you have the following plausible options: 1. Fix it yourself 2. Convince a technically-minded friend to fix it for you 3. Raise awareness in a positive manner such that developers *want* to fix it because they think that working with you on it will be a fun experience 4. Start a bug bounty for this issue and help it to grow to a large sum ($1000 or more) 5. Directly pay a developer to fix it Pick one. Note that complaining in public isn't one of the effective options. :)
I don't think it's a complaining in public. This is bug tracker after all...
(In reply to Nate Graham from comment #130) > To reiterate: posting negativity makes people capable of fixing this issue > less likely to do so rather than more, because dealing with you will seem > like an unpleasant experience. Whining and complaining in pubic is thus > counter-productive. Sorry to hit you with the hard truths, but that's just > how it is. :) > > If you're desperate for this to be fixed, you have the following plausible > options: > 1. Fix it yourself > 2. Convince a technically-minded friend to fix it for you > 3. Raise awareness in a positive manner such that developers *want* to fix > it because they think that working with you on it will be a fun experience > 4. Start a bug bounty for this issue and help it to grow to a large sum > ($1000 or more) > 5. Directly pay a developer to fix it > > Pick one. Note that complaining in public isn't one of the effective > options. :) Maybe you are right that this is the reality. But, however, such a mindset does not actually convince people that the devs contributing to KDE are very professional. If they don't really want to contribute to get this fixed then maybe an open source project is not the right thing for them to do and they should just leave the field to someone else who actually wants to give other people working software. Pretending to be willing to fix such a bug and then just doing nothing certainly is not the right way! And I really don't care if I am pissing somebody of with this because it's the truth. Actually, this mindset of a lot of people in the open source community is one of the reasons why most people use commercial software. It's just tiresome to deal with such people. But nevermind! I don't have to deal with this crap anymore. I will just never use plasma again.
Bug reports should provide, in some way, information that may lead to a resolution. i.Dark_Templar's above-and-beyond work is an extraordinary example, as is Mike's original report and other's showing it to be more widespread. But, it isn't going to be helpful, 5 years later, to simply state it still exists in version # or asking for a progress update. Florian, you'd be doing yourself a service (especially if you "will just never use plasma again") by removing yourself from the CC list. No need to be notified of nor participate in something that no longer affects you.
My posts doesn't meant to start a flame war. I just wanted to report the bug is still here and I'm wondered nobody cares at all. It's beyond my mind how a release can be LTS with such bug. Many LTS versions actually. And everybody throws their efforts in many insignificant bugs or extras, instead of looking at the real serious bugs like this bug. And this bug too: https://bugs.kde.org/show_bug.cgi?id=420903 The desktop is the face of the Desktop Environment, hence these bugs should be treated with extra high proirity. Don't make users feel guilty for reporting your bugs. There's no point of this bug tracker at all if you want they fix bugs themselves.
Nick, evidently this bug is priority #1 for you. But unfortunately for you, clearly is it not as high a priority for the developers, because we are fixing other things rather than this. It is telling that you see all of that other work as "insignificant." I understand that it seems that way to you because this specific issue is your top priority. But for people who are not you, other issues are their top priority. Understand that if somebody spent a few days fixing this, they would be neglecting other issues, and people in those other issues would be saying the same things there. "Developers don't care!" "How can this bug still exist after X years!?" etc. The very difficult job of a developer is to figure out whose top priority to prioritize, because there are always more bugs than there are hours in the day to fix them. That time is previous, and discussions like this consume it and make people feel exhausted. I have now spent over an hour reading and writing text in this bug report today. Not fixing the bug. Not investigating it or scoping out work. Just participating in this discussion. That's time I haven't been spending on actually getting anything done. But of course, when developers stay out of discussions like this because they *do* prefer to get things done, people complain that developers are ignoring bug reports and disrespecting users. Have a little empathy. This is a hard job. If you want to help this bug get fixed. I provided a list of 5 potentially effective actions. Complaining about it in the bug report or posting "this is still a problem" after every release is not one of those effective actions. :)
Nate, Hello, I only intervene very little. I would just like to say that here it is a usability bug. When you tidy up your desk and find it a mess, it quickly becomes frustrating. From the years that this bug has existed, we really have to ask ourselves: do we really want users to be able to put things on the desktop. I'm also a developer, and it's no excuse to say you need to fix something else. This form of excuse would be valid if the bug had not existed for so long. Likewise, number 5 on your list makes no sense. You don't know if the person is donating to KDE. People often donate in the hope that the bugs they encounter will be fixed as soon as possible. I myself have a new very annoying bug, I can no longer open items on the desktop by double clicks. But that doesn't bother me because Linux is only a secondary OS for me to do my validations. If I had to use it every day, this bug would be of great importance for me to correct because my desktop is a transition space for my documents. Unfortunately, my experience with bugs reported to developers has always gone badly. Bugs are not crawled for months or even years after they are opened. I report very few bugs in free software because I am discouraged by the time it takes to process tickets. (I'm talking about the time it takes for someone on the team to read it) When I read developer comments like the one you made, I am saddened by how little empathy you have for users who experience usage bugs. Also think about the reaction of people who find out the age of this bug.
If you're a developer, can you help fix it?
I was going to say the same thing, but also add that it's already been said that they can't replicate the issue on their side. That makes fixing the issue much harder. And if you have other bugs reported to you that you can replicate or have a backtrace that makes finding the cause easier, it's a no-brainer to attack those bugs first rather than poke around in other code to try to blindly figure out why a desktop quirk is happening (with no idea how long it'll take to find it) and leaving those easier bugs untouched.
(In reply to Nick Stefanov from comment #134) (In reply to Nate Graham from comment #135) I'm not KDE dev, so I don't know their priorities, but I guess one important point might be missing: issue might not reproduce at all or often enough for devs or people willing/capable to debug and/or fix it. I guess that bug happens often for Nick Stefanov, but doesn't happen at all for Nate Graham. For me, after I created first patch and later used fix by Eike Hein, similar issue reproduced only once, which I mentioned in https://bugs.kde.org/show_bug.cgi?id=354802#c107. That is hitting issue once in almost two years, and on average I'm logging into KDE X11 session around once a day. If I include times when I do it more than once a day, I can say that I logged into KDE over 1000 times since applying a patch. 1/1000 reproduction rate - bug practically never reproduces for me anymore on it's own. There is just not enough information to reproduce it at least somewhat reliably, I guess.
(In reply to Nate Graham from comment #135) > Nick, evidently this bug is priority #1 for you. But unfortunately for you, > clearly is it not as high a priority for the developers, because we are > fixing other things rather than this. It is telling that you see all of that > other work as "insignificant." I understand that it seems that way to you > because this specific issue is your top priority. But for people who are not > you, other issues are their top priority. Understand that if somebody spent > a few days fixing this, they would be neglecting other issues, and people in > those other issues would be saying the same things there. "Developers don't > care!" "How can this bug still exist after X years!?" etc. > > The very difficult job of a developer is to figure out whose top priority to > prioritize, because there are always more bugs than there are hours in the > day to fix them. That time is previous, and discussions like this consume it > and make people feel exhausted. I have now spent over an hour reading and > writing text in this bug report today. Not fixing the bug. Not investigating > it or scoping out work. Just participating in this discussion. That's time I > haven't been spending on actually getting anything done. But of course, when > developers stay out of discussions like this because they *do* prefer to get > things done, people complain that developers are ignoring bug reports and > disrespecting users. > > Have a little empathy. This is a hard job. If you want to help this bug get > fixed. I provided a list of 5 potentially effective actions. Complaining > about it in the bug report or posting "this is still a problem" after every > release is not one of those effective actions. :) Don't get me wrong, Nate. I don't depreciate dev's work. On the contrary - all of you make wonderful work and that's why KDE is the greatest DE ever. But please understand - this bug isn't priority #1 just for me. If a bug exists only in one DE, it's a real problem. If a bug is on the face of that DE, that's a realy big problem. Think about it - even Windows 95 works better in this regard. Every DE have a desktop and everywhere it's used with one single purpose. We can't use our desktops and that's a big problem. That's it.(In reply to vindicator from comment #138) > I was going to say the same thing, but also add that it's already been said > that they can't replicate the issue on their side. > > That makes fixing the issue much harder. And if you have other bugs reported > to you that you can replicate or have a backtrace that makes finding the > cause easier, it's a no-brainer to attack those bugs first rather than poke > around in other code to try to blindly figure out why a desktop quirk is > happening (with no idea how long it'll take to find it) and leaving those > easier bugs untouched. What about this 100% reproducible bug? https://bugs.kde.org/show_bug.cgi?id=360478 Nobody look or work on it. And the bug may be relatively new but actually the problem is here for years, even in KDE 4. Nothing, zero effort, zero interest from devs. It's a very good occupation for users to rearrange their icons X times a day. I also like it. What I'm sayng? I adore it.
Nick, "100% reproducible bug"? Yet your own comment https://bugs.kde.org/show_bug.cgi?id=360478#c92 "Sometimes it's working but not always" "zero interest from devs"? When you quote Feck's comment with yours in https://bugs.kde.org/show_bug.cgi?id=360478#c91?
Now it's again 100% reproducible. I can make a video. Every time you start an application with a lower resolution than the current and your icons are getting scrambled. Every single user or dev can try it. Nothing.
I mean the following - have one icons column (14-15 icons) on you r desktop from top to bottom at FullHD resolution. Now start a game with a lower resolution, 1024x768 for example. Exit the game and your icons will be on two columns. This is 100% reproducible and I think it's the root of this bug which we are discussing. Before: https://i.imgur.com/vwX5A0w.png After: https://i.imgur.com/xH8ySQs.png
I have no doubt that this bug is 100% reproducible; it's well understood. The reason why it hasn't been fixed, ultimately, is that it's just not that significant of a bug, I'm sorry to say. Why do I classify it as such? Because it's a cosmetic issue with a known workaround that only affects people who switch resolutions a lot--principally people who play very old video games, or modern games on severely underpowered hardware. It's annoying, and it has a lot of duplicate bug reports. True! And those are reasons to fix it. Definitely. But, it's a mere annoyance and there's a workaround. The bug doesn't delete your files. It doesn't block login. It doesn't cause any apps to crash. It doesn't render any features unusable. And it doesn't effect everyone, just people who play certain video games (I'm simplifying). So hopefully that provides some context, from my perspective as a bug triager, for probably why it hasn't been fixed yet. I get that it's important to people who *are* affected. The desktop should not be annoying. Totally. I'm sure it will be fixed eventually. If you want that to happen faster, I already provided a list of 5 things that can help. :)
I think if it will be fixed, it should solve this bug too. You say there is workaround? Where, I obviously missed it :)
I don't know if this might be of any interest, but wouldn't it be possible to use some sort of matrix representing the position of the icons in a given resolution and when changing to a smaller one, use the latter for reposition the icons in the original resolution.
Or they just can see how it's achieved in every other DE and I'm sad to say it - even Windows.
(In reply to Nate Graham from comment #130) > To reiterate: posting negativity makes people capable of fixing this issue > less likely to do so rather than more, because dealing with you will seem > like an unpleasant experience. Whining and complaining in pubic is thus > counter-productive. Sorry to hit you with the hard truths, but that's just > how it is. :) Yes, after 5 YEARS of kissing some phantom dev's ass, offering availability to help nothing has happened. Wrooooong strategy. > If you're desperate for this to be fixed, you have the following plausible > options: > 1. Fix it yourself > 2. Convince a technically-minded friend to fix it for you > 3. Raise awareness in a positive manner such that developers *want* to fix > it because they think that working with you on it will be a fun experience > 4. Start a bug bounty for this issue and help it to grow to a large sum > ($1000 or more) > 5. Directly pay a developer to fix it > Pick one. Note that complaining in public isn't one of the effective > options. :) I picked up NUMBER SIX: use ubuntu with Gnome 3. I REFUSE to go back to KDE (which always used to be my fave DE) UNTIL this RIDICULOUS bug gets fixed. I don't play games, I don't switch resolution and the bug was still there till I installed ubuntu. Now, finally, it's gone. Finally effective debugging. You have been already told that even the infamous win 95 didn't have such annoying bug and you devs spend time beating yourself up with arcane mumbo-jumbo while the FRONT LINE OF YOUR PRODUCT IS FLAWED, dancing icons on the desktop are one of the first things every "lucky" one notices. You really must be out of this world guys, wasting so many hours of your life in order to make the perfect software and getting turned down by the very first grandma using KDE and asking "why the hell don't these icons stay where I put them?". Come back down to Earth, realize that a product that does annoy the user ain't really gonna "konquer" the world. Sincerily yours Pasha
Plasma 5.20.4 - it's all the same. Nate, will be another deadline for this important problem? And do you plan another talk with the devs?
Plasma 5.21 and it's still here. And the double icons too: https://i.imgur.com/TbpxHAA.png Random icons get double mark area after some time and I don't know when. If I shut down my monitor for a while or when the resolution is being changed, I really don't know but I see them everyday. If I take the icon and move it, the problem disappears and I can return it to it's previous place with normal outline.
And here we come again. The icons got scrambled even without a restart, I just turned off my monitor for a while. When I turned it on again I found this: https://i.imgur.com/j7gfo5W.png I left them like this: https://i.imgur.com/w6ZIHcD.png And what's the most ridiculous is I can't rearrange them: https://youtu.be/5G9J6COKUQ8 How can you devs sleep at night with such ridiculous bug? I can't imagine nobody look at this, this is madness! It isn't some alpha DE, it's the famous KDE Plasma with numerous versions behind, many of them LTS. Is this what you call LTS? In 2021 we still chase our desktop icons and can't arrange them as we like. Epic fail...
Nick, I hope you understand that the more noise you make in this bug report, the more you're annoying the developers who are capable of fixing the issue and making it less likely they they will ever want to work on it. This is not a commentary on optimal user-developer relations, or whether or not the priority of this issue should be adjusted. I'm just telling you like it is: your current approach is not effective at making this bug get fixed any faster.
(In reply to Nate Graham from comment #152) > Nick, I hope you understand that the more noise you make in this bug report, > the more you're annoying the developers who are capable of fixing the issue > and making it less likely they they will ever want to work on it. > > This is not a commentary on optimal user-developer relations, or whether or > not the priority of this issue should be adjusted. I'm just telling you like > it is: your current approach is not effective at making this bug get fixed > any faster. I must admit: I didn't yet sign out of this surreal bug report because I was so damn curious to see to which level clownish answers like such could drop.. come on, darling! Keep on pissing off kind cooperative users who would like to help closing this outrageous bug, more than 5yrs old now, light up the candle on its anniversary cake! Btw, my gnome3 desktop would also like to learn how to scramble icons, maybe you could help teaching!!! You really got the attitude of a good teacher!
(In reply to Nate Graham from comment #152) > Nick, I hope you understand that the more noise you make in this bug report, > the more you're annoying the developers who are capable of fixing the issue > and making it less likely they they will ever want to work on it. > > This is not a commentary on optimal user-developer relations, or whether or > not the priority of this issue should be adjusted. I'm just telling you like > it is: your current approach is not effective at making this bug get fixed > any faster. When there was no noise, nobody looked at it. When there's noise - it's all the same. I want to make you understand how absurd is this bug for any DE and working on a fix should be with the highest priority.
(In reply to Nate Graham from comment #152) > Nick, I hope you understand that the more noise you make in this bug report, > the more you're annoying the developers who are capable of fixing the issue > and making it less likely they they will ever want to work on it. > > This is not a commentary on optimal user-developer relations, or whether or > not the priority of this issue should be adjusted. I'm just telling you like > it is: your current approach is not effective at making this bug get fixed > any faster. I can't agree with you in any way Nathan. If no noise is made, the bug will sink forever into the abyss without ever being resolved. If the developers don't want to be bothered with this bug anymore, let them work on fixing it. You yourself, I asked you a question in a bug asking you what I had to put in addition to provide the most information to resolve a bug on the desktop and you never answered me. So, before you go after users who are annoying, start by answering those who ask you questions to help you and other KDE developers solve bugs.
The weirdness continues: https://i.imgur.com/FEQyA9C.png Something is so screwed up...
Guys, just do it like I and Pasha did and switch to another Desktop Environment where the basic features actually work. They won't fix this issue anytime soon. Like Pasha, I am only here to see how ridiculous the arrogant reactions of the developers actually can get. It is kind of sad because Plasma has always been a very good Desktop Environment. At some point, however, I got the feeling, you had to worry that another stupid bug occurs once you updated Plasma....
Plasma 5.22 - The problem is still here.
I've used kde for over 20 years - it might be even 25 - I forget, but it was in the 90's for sure. Never had the problem until now using a fully updated KDE Neon, which is quite bleeding edge. However, this install worked fine until my P/S died and I moved the hd into a different box entirely. Other than being only slightly slower - if at all (2 core, bios is 2009, 6GB) - the only real difference is that my second monitor is now HDMI <---- I think it's this somehow. It happens with opengl and xrender. It happens during a session. I don't have to reboot and it scrambles the icons. Set to manual. Locked or unlocked makes no difference. This is indeed a very old bug I see from this thread and also a duplicate. Maybe this helps someone familiar with the code.
All I need to do to make the icons move is turn the hdmi monitor off and then on again! I am not kidding. I do nothing but turn the monitor off and on and the icons mv by themselves. It doesn't matter if they are locked or not. Sometimes it ignores the 'manual' setting and arranges them as if it weren't set. Other times they seem to move to random positions. I read somewhere on here that different resolutions might play a role. Perhaps the hdmi monitor steps through some as it acquires the signal from the computer. IDK. Anyhow. No need to reboot, logout or do *anything* but turn that monitor off and on to trigger the bug. The other monitor is vga and both are just coming off the motherboard (bios says 2009) and not a special video card. I hope this helps to track it down. I never had the bug until I hooked up this hdmi monitor, so it makes sense that way at least too.
(In reply to kdebugtracking from comment #159) > I've used kde for over 20 years - it might be even 25 - I forget, but it was > in the 90's for sure. Never had the problem until now using a fully updated > KDE Neon, which is quite bleeding edge. Of course it happens my friend, this bug has now become a *feature* :D which other DE in the world could boast "dancing icons"???? Stop acid digestions and join the club of me and Florian who are using another product. I know that you got used, I was too, but afterwards you will breathe seamlessly and forget about this ridiculous story.
this bug indeed is ancient and possibly never dissapears. But the last comment about hdmi is at least here not fitting: I initially had the bug on my workstation with an HDMI monitor but since I upgraded m hardware to a ryzen7 5700G I never had the bug biting me...;BUT...on an older Lenovo ThinkPad (T500) almost on any boot with the same.manjaro system as in m desktop all icons get scrambled...; And on the laptop it's the integrated screen ...where it happens ..on the workstation over HDmi it's stable. My sDtem before where it happens also was very old... Athlon x2-250 and an nvidio Gtx650ti... ; for me it looks like old hardware has an influence...?
A good point Mike - I didn't do just one thing and make one change - I made many hardware changes at once. This SSD was sitting in a m/c only a few years old when its p/s died and my town is too small to have a store for parts, so I built a pc out of old ones. The KDE Neon install suddenly 'woke up' to find itself in a body composed of an old 2009 box and with an HDMI output for a second monitor instead of DVI. Maybe it's the combination and the bug is peculiar to a certain chipset + HDMI, at least for *this* bug. I have read around and seen that 'dancing icons' was caused before a couple of times by something entirely different that got fixed. I was just flabbergasted that I could make it happen by toggling the power switch on the monitor. Hard bug, b/c it is so rare. I'm not a single data point. I've supported KDE on desktops in many homes and businesses for decades and never encountered this bug until now. After reading through a bunch of similar bug reports, it seems that 'dancing icons' is more of a syndrome - a symptom like pneumonia, something with many possible causes vs a single 'disease'. Since it only effects me (in gemlog's little world, at least), New Plan: I will simply rename the icons I care about with numbers and let the desktop sort them by name and forget about it! :-) Thank you all for sharing your experiences.
I have this problem with DP interface and NVIDIA GTX 1080Ti. My brother is with DVI-D and NVIDIA 1050 and he also experience this problem. We are with different monitors. Nevertheless, you can always reproduce the problem when set icons on the left from top to bottom and then lower the current resolution. It's 100% reproducible.
It's an intriguing problem isn't it? :-) I can grok how, depending on how the icon positions are stored, could be effected by a change in resolution. I don't get why all the icons aren't translate to new positions in a uniform way. How some icons remain in place and others are flung across the display seemingly at random. Maybe relative positions are stored and some 'wrap' around the edge? I really have no idea.
The funny thing is the devs don't have idea too.
Plasma 5.23 - the bug is still here.
"Scrambled" means what? I have to observe three effects in this context, in addition to #360478: 1. Icons are 'moving about'. I filed this as well. This applies especially to displays of widgets that change size, like fuzzy clock. 2. At times (roughly once per twenty boots) all settings are gone, my desktop background image doesn't show, instead the default kde desktop is displayed, with my 20+ icons 'nicely' arranged in regular rows, starting in the upper left corner. 3. Only the Chromium icon (does it have to do with snap?) disappears for good. It never comes back, just 'empty' with the caption still there, and clicking the empty space brings chromium up. So once per fortnight I need to re-add it to the desktop. It stays, and survives a number of boots, maybe a dozen, before it doesn't pop up. Rinse and repeat. Workaround for 1 and 2 is the config saver applet. It does not work for 3.
I have the same problem, every so often the icons lose their custom order and are arranged only horizontally starting from the top left. The wallpaper I chose is changed to the one that comes by default. All plasmas that I put on the desktop are lost. Apparently the file ~ / .config / plasma-org.kde.plasma.desktop-appletsrc is replaced by its default version at some point during KDE startup. Under this hypothesis, I decided that to prevent the custom file from being lost, it was best to put it in read-only mode during the entire startup process and to return to read-write mode only when the startup had finished. To achieve this I made a script that runs automatically at KDE startup: ............................................................................................................... #! /bin/bash chmod 444 ~/.config/plasma-org.kde.plasma.desktop-appletsrc sleep 30s chmod 744 ~/.config/plasma-org.kde.plasma.desktop-appletsrc ................................................................................................................... I also added a script that runs during the log out process .................................................. .................................................. .. #! /bin/bash chmod 444 ~/.config/plasma-org.kde.plasma.desktop-appletsrc .................................................. .................................................. .. And it is working flawlessly to this day. My system is: Sistema operativo: Manjaro Linux Versión de KDE Plasma: 5.23.3 Versión de KDE Frameworks: 5.88.0 Versión de Qt: 5.15.2 Versión del kernel: 5.15.2-2-MANJARO (64 bits) Plataforma gráfica: X11 Procesadores: 2 × AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ Memoria: 3,8 GiB de RAM Procesador gráfico: GeForce 210/PCIe/SSE2
It's so sad using such workarounds in 21st century for such basic things in DE which calls itself advanced...
Thanks, Chango, for #170! Because it confirms my own observation, here and in other bugs, that it is not just a predictable problem of shifting around icons at changes of resolution, as mostly tackled in here. I am 'glad' that it is not only me, who experiences a loss of all settings, default desktop background and 'listing' of all icons at some boots, though infrequently. Despite of a physical setup with any modification w.r.t. cables et al, sometimes at login to KDE it seems that the built-in screen is activated first, before switching to the external monitor; while some times it is the external monitor that is activated immediately. How do I know? In the first case, all icons are positioned in the upper left corner, exactly filling the area implemented by the laptop screen. Meaning, that during startup the resolution of the laptop screen is read and applied briefly. (Then I reset the icon locations) Some times the icons remain at their pre-allocated positions on the monitor with a larger resolution; indicating that the monitor switch as set in the System Settings (internal monitor disabled) happens earlier, before getting the external monitor up. In a nutshell, you seem to confirm my suspicion, that the plasma desktop goes through unpredictable phases and sequences at its start-up. I didn't look at the details, but I can imagine that it has to make with task parallelization, like with systemd. In any case, the plasma desktop is brought up in a non-reproducible, non-controlled, not predefined sequence, so it looks like. Your workaround confirms this: During startup, certain processes read and write configuration files at undefined moments of the sequence. With some bad luck (it happens once per around 50 or 70 start-ups here) it doesn't find what it is looking for, and subsequently starts its layout from scratch. The passage through initial laptop display respectively immediately bringing up the external monitor immediately rather is distributed 1:1 here. (I really wonder if the kde developer use their own product, or have likewise implemented workarounds for their machines?)
In "Desktop Folder Settings", and in the "Icons" category, there is a setting called "Arrangement", with the possible values being "Rows" or "Columns". When I had this set to "Columns" (the same behavior as in Windows), my desktop icons would be scrambled very frequently during login/unlock/awakening from suspend. To cut a long story short, I have reverted this value back to "Rows", and I have yet to have the scrambling occur. This might be an acceptable work around for many people, and perhaps it is the reason why the devs have been unable to successfully replicate this bug since they are using the default value. For the record, I am also using an nvidia GPU; I have a sneaking suspicion this is somehow related since it has caused many other glitches with KDE.
I think I can alieve you of your "Nvidia" "sneaking suspicion" with comment #7 (https://bugs.kde.org/show_bug.cgi?id=354802#c7), as well as my case being under the use of a very old Haswell IGP.
It's not NVIDIA, the bug appears on Intel GPUs too.
*** Bug 441477 has been marked as a duplicate of this bug. ***
I found this thread on the manjaro forums that fixed it for me (not sure if it is the same bug tho), seems to be a glitch where the folders-first checkbox is checked even though manual sorting is selected, which is impossible in the settings page, but possible to set in the right-click menu. https://forum.manjaro.org/t/kde-plasma-does-not-remember-the-location-of-desktop-icons/68636/14 (I use NixOS btw)
It's hilarious in 2022 we are still talking about this...
@Zyansheep, alas, no. Thanks for #177, but we deal with a different item here. I cannot fathom that we have so far not had a single reply from KDE e.V. on how to handle the desktop in case of variations in the real estate. There seems to be no explicit rule. Once real estate grows, the icons are left where they are w.r.t. 'Zero' of X, that is (0,0) == upper left corner. Not necessarily nice, though working. If, however, real estate shrinks, there also seems to be no other rule than just not to discard the icons for which the locations might be gone. So they will be splattered (with a process unknown to me) across the remaining real estate. I didn't follow the design decisions of - by now - a decade ago. Maybe those people have moved on by now. Whatever, though, and maybe I am wrong here, until today nobody of the relevant authority has decided on or published a rule on the handling of (mostly) icons on the Plasma desktop in case of changing geometrical properties. Therefore, this bug is not one of code which could be rectified with a certain ease. The bug is - I know, I only repeat myself - a bug of the design ('architecture'). As long as no rule is set out, there is no code possible in this world to implement that rule. Of course, I have been available to discuss some possible rules plus their consequences; in order not to just be a nay-sayer. Though, I am not aware of any serious attempts to advance by the KDE project in this respect.
For me Plasma (5.24.2) changes custom icon position on almost every restart. Moreover Plasma changes custom icon positions on screen resolution change (e.g. run old game or change to lower resolution manually and go back). Plasma doesn't take advantage of possible scroll bars - it mustn't change position of icons on Plasma resize - it should display scroll bars. They will disappear when size go backs to normal, otherwise the user can sort icons manually.
"on almost every restart" Look further up. I think we have to make with two items. One is the placement of icons on the desktop in case of real estate changes. You'll find everything under #360478. Aside of changes of icons (like desktop background), we probably see effects of another bug that isn't triggered by changes of desktop real estate, but rather as random occurence only at boot. Which points into the direction of systemd. I myself have observed some occasional messed-up behaviour (see above), including just not being able to process password input at login; exclusively after a boot. Meaning, the built-in keyboard isn't read properly and multiple efforts will never allow me to enter my password properly. After a reboot, everything works fine. Make this a once out of 10 cold boots. (And, no, yes, the keyboard(s) will work 100 percent during hours of typing session - keyboards: this behaviour is - if this happens - identical on the built-in keyboard and the external keyboard; so it is DEFINITELY not a keyboard problem!) I' d really wish we could split and clearly distinguish the underlying situation despite of - at first glance - similar outcome: 1. Messed up icons (and desktop, and other stuff) solely at *boot -> pointing to systemd-dependencies (this bug) 2. Messed up icons solely at change of real estate (seemingly random positioning of icons whose locations don't exist after a downsizing of the canvas (#360478) ) What unifies these two bugs is only their ages of >6 years, and their major blocking of kubuntu to be 'useable by the average person out there'. Having been sysadmin for 20+-years, I wouldn't want to having anything to do officially with such a system once a user filed a ticket for either. Some 20 years ago, such bugs were good material for jokes about Redmond.
(In reply to Uwe Dippel from comment #181) wouldn't want to having anything to do > officially with such a system once a user filed a ticket for either. Some 20 > years ago, such bugs were good material for jokes about Redmond. Unfortunately that's the reason I install Mint Cinnamon for other people. I migrated over 500 users to Linux and none of them is using KDE because of this ridiculous bug. I love Plasma and I can fight it's bugs everyday but I can't want from people to do the same. They'll rather back to Windows which is sad.
Well, Nemo (which is used in Mint) has a similar bug that drove me crazy when I was still using Unity: https://github.com/linuxmint/nemo/issues/2596 I was really dissapointed when I found out that KDE has the same issue. But otherwise it is pretty functional and I hope this gets fixed eventually.
*** Bug 452506 has been marked as a duplicate of this bug. ***
(In reply to Nick Stefanov from comment #178) > It's hilarious in 2022 we are still talking about this... Well, buddy, that's why I still have subscription to this bug report, I want to see where the telenovela goes, while eating popcorn :((( After all, if even during lockdowns no developer struggled to fill the bill of this outrageous ageing bug, well, it's a lost cause... All the chickens in redmond are laughing up like crazy!
Not sure, is this the same issue as Bug 360478 (fixed)? If it is, then we can close this one as a duplicate?
I was just noticing myself that it seems to be fixed now! I wanted to do a bit more testing before formally calling it fixed. But yeah, great work.
Read this surprisingly... because I didn't had those bug experience for a long time - after my hardware upgrade never again...but 2 days ago and even today just on reboot all icons are scrambled again :-o . Oh noooo.... Still on Manjaro 5.15.28-1 Plasma 5.24.3 Kernel 5.15.28 X11...;
(In reply to Mike from comment #188) > Read this surprisingly... because I didn't had those bug experience for a > long time - after my hardware upgrade never again...but 2 days ago and even > today just on reboot all icons are scrambled again :-o . Oh noooo.... > Still on Manjaro 5.15.28-1 Plasma 5.24.3 Kernel 5.15.28 X11...; Note that the bug fix in question is only in 5.25, not 5.24.x
oh...thanks ! Didn't realized that. So I wil happily wait for the next Manjaro update.
Yep, tested this six ways to Sunday and it's definitely fixed now. Hallelujah! Thanks so much, Bharadwaj! Because that makes https://invent.kde.org/plasma/plasma-desktop/commit/2dca17060c06f85abc365bab9484ee4446d78772 a bugfix, we can consider backporting it to 5.24! I will investigate some more.
I have this issue in a computer but I was always thinking that was an issue because we shutdown often the computer manually with the button. I hope to see the new version soon to update the machine!
Git commit 8f85c4658adfdf7a01c591afd79baa9eed8b79dd by Nate Graham, on behalf of Bharadwaj Raju. Committed on 17/04/2022 at 18:55. Pushed by ngraham into branch 'Plasma/5.24'. Folder View: save desktop containment icon positions on a per-resolution basis Related: bug 360478 FIXED-IN: 5.24.5 (cherry picked from commit 2dca17060c06f85abc365bab9484ee4446d78772) M +1 -14 containments/desktop/package/contents/ui/FolderView.qml M +29 -3 containments/desktop/package/contents/ui/FolderViewLayer.qml M +1 -0 containments/desktop/plugins/folder/positioner.cpp https://invent.kde.org/plasma/plasma-desktop/commit/8f85c4658adfdf7a01c591afd79baa9eed8b79dd
There is one remaining way that I can find for the icons to be scrambled on boot: when you're using Wayland with screen scaling, sometimes the scale isn't initially applied properly, causing the desktop to be blurry and icons to-re-arrange themselves because they think there's not enough room. This is tracked by Bug 449212, so if anyone is still seeing scrambled icons happen on Wayland with the desktop blurry right after boot, that's the bug report you can follow to be notified when it gets fixed.
Not fixed... Video: https://mega.nz/file/B59UVAYL#ItyK9VdM5FeYLMyar7IusSQKEMszzWt-cbsmBJe2bUg
Created attachment 148612 [details] https://mega.nz/file/B59UVAYL#ItyK9VdM5FeYLMyar7IusSQKEMszzWt-cbsmBJe2bUg https://mega.nz/file/B59UVAYL#ItyK9VdM5FeYLMyar7IusSQKEMszzWt-cbsmBJe2bUg
Not solved on 5.24.5
Your video depicts a separate issue, possibly Bug 359783 or a variant of it. Please file a new bug report about it. Thanks!
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 just hit the update on manjaro stable, this bug still occuring , left/right row or column alignment items locked or unlocked, after every logout/login they are scrambled, although it doesnt seem random but rather in same way everytime (for example row alignment causes them to be in a sort of staircase pattern next login that is same everytime)
what i just dont understand is why the "plasma-org.kde.plasma.desktop-appletsrc" file in the user home gets overwritten at all. if it already exists it shouldnt be changed by a login like ever.. i tried locking the file in readOnly mode it still gets touched and items are scrambled so only workaround is to autostart a script that changes that file agian...
still also happens but not always on running "pkill plasmashell && kstart5 plasmashell" just tested this too, every 2nd or 3rd time that command changes deskto item positions aswell..- pls remove any codepath that touches that file during plasmashell start!
Ok this might be a slitghtly different issue but the desktop icons still get scrambled and if i run the command cp -v ~/.config/plasma-org.kde.plasma.desktop-appletsrc.bak ~/.config/plasma-org.kde.plasma.desktop-appletsrc followed by the usual plamsashell restart: kquitapp5 plasmashell && kstart5 plasmashell the desktop ends up in a weird state where the icons show up where they belong as long as the focus is on the terminal, but when clicking anywhere on teh desktop the icons show up scrambled and on different positions. PLS PLS someone fix this issue for good, this is the nr1 reason i have to install xfce desktops on new linux user pcs because this happening every reboot/login would just drive em away from linux again.... at this point i am willing to pay for this to get fixed for real.
Please file a new bug report as the original cause of this one has been fixed. There might be new causes, but those need new bug reports.
(In reply to Nate Graham from comment #203) > Please file a new bug report as the original cause of this one has been > fixed. There might be new causes, but those need new bug reports. what policy is that? the bug description and everything in it fits the issue i have exactly, THIS bug is not fixed, creating a new one with exact same description will just lead to it not being found and not gaining any credibility, so it can be ignored for 6years again? There was a commit that claimed to fix this and it didnt: THIS BUG IS NUMBER 1 REASON u cannot install KDE to new users who dont want windows11.- and the action is to just ignore it and put it on "CLOSED FIXED" ? I am here telling you and whoever claimed to fix this, i can pay you if this gets finally fixed for real! And to anyone coming here from google, and co: THIS BUG IS NOT FIXED,.. it is very much still happening and 100% reproduceable every single logout/login, you are not the only one and your install is not at fault.
The policy makes sense to me, it really does seem to be fixed for the majority of cases. Of course you are welcome to link (I would recommnend it) this bug from the new bug and vice versa. (anw what you describe sounds to me maybe more like a consequence of the fix for this bug).
Hmm, after some time without any problems, today my icons get scrambled too at powering my PC.
Again, that means we have fixed *one* cause of the bug, but evidently there are more. So we need *new* bug reports to track these heretofore undiscovered additional causes of the bug. So if you are still experiencing it, please file a new bug report and add "354802" to the "See also" field.
Nate, this is the same nasty bug. What's the point to post a duplicate with the same title? Today my icons get scrambled again when I rebooted my PC.
Once again, though I had decided to keep mum, but that was on the other bug', here I have to side with Nick. The 'boot up problem' (of supposedly systemd) ISN'T gone. Don't want to yadayadayada-repeat myself for the umpteenth time, just see my posts above, ALL are still happening here. (We ARE off the 'scrambling at resolution change', confirmed, solved.) This one IS more difficult, because here scrambling, non-working keyboard, disappearing Desktop background are not easily reproducible, they just occur at random, and not frequently. Again: This is an ONLY AT BOOT problem. Subsequently difficult to follow up. So I would actually volunteer, again, if I could help with some specific log file that I'd harvest directly after some reboot when one of those errors occurs.
I told you what you need to do: open a new bug report for your issue. The reason is because even though the issue you're experiencing may be the same as the issue tracked here, it clearly has a different root cause. This bug report was about *one* root cause of the issue, and that one got fixed. But wou found another one. Yours will require a new investigation and a new fix. Hence, we should track it with a new bug report, so that the people CCd on this bug report for whom the issue is already fixed don't get spammed with a zillion new comments. Please file a new bug report. It's not that hard.
Folks, if they want you to create a new report, just do it and link back to this thread stating its long-standing age, along with the associated title "Desktop Icon position gets scrambled sometimes on reboot". (emphasis on "reboot") All parties get what they want. I would disagree that a new report should get created if the title still stands true. If the title is no longer true, then the report is "closed fixed". Having "fixed" ONE cause (where others still may remain), doesn't mean the title is no longer true. Other reports would be considered "duplicate" in my view.
No idea if kded has anything to do with saving desktop icons but might a this fix: https://bugs.kde.org/show_bug.cgi?id=97716 also fix the remaining issue with this? It kind of sounds similar.
i created new bug for those still expirencing the issue here: https://bugs.kde.org/show_bug.cgi?id=454345
(In reply to William from comment #213) > i created new bug for those still expirencing the issue here: > https://bugs.kde.org/show_bug.cgi?id=454345 So now fun has been tranfserred to the other "bug channel"... too bad you were obliged to open it, this is ruining the astounding 7 years record of this one by some maquillage... this is pretty unfair! And there is some nerd claiming that the bug has been "squashed" (this "CLOSED FIXED" status belongs more to a Mr. Bean show rather than serious IT), while it's still there... 1 cause, 2 causes, n causes... the bug is still there, granny still complains about her dancing icons... so policy is: make it look like a bug squashing community, but "run it like politics" i.e. show some fake progress and relax, it's not your problem! (...and, after all, it's a pretty recent bug, just 2 weeks old, isn't it?) P.S.: gnome 42 works great, can also default file manager to nemo
OPEN
open
(In reply to EspadaRunica from comment #216) > open There is already an open issue about it, https://bugs.kde.org/show_bug.cgi?id=454345. Don't spam here.
Not fixed in 5.25.4 https://i.imgur.com/V46TYof.png
Can I ask the people for whom this is still broken to file new bug reports? In this one, evidently we fixed one part of the problem, but if it's still partially happening for other use cases, it's much more helpful if we track those issues with new bug reports, rather than using this one as a monster that tracks everything. It helps. Thanks.
(In reply to Bharadwaj Raju from comment #217) > (In reply to EspadaRunica from comment #216) > > open > > There is already an open issue about it, > https://bugs.kde.org/show_bug.cgi?id=454345. Don't spam here. The open topic is wrong, something that was already open cannot be opened. It was never fixed.
(In reply to EspadaRunica from comment #220) > The open topic is wrong, something that was already open cannot be opened. From everything I can gather, it isn't wrong and it is the bug you want. If you think otherwise, file a new one. Point is, stop spamming "OPEN!!!1" etc comments here. > something that was already open cannot be opened. Then add yourself to the CC list and follow the progress. > It was never fixed. The bug had multiple causes by which it could manifest. One cause was tracked and *fixed* here. Other causes are tracked elsewhere as it is easier. Is this concept really so difficult to understand?
(In reply to Bharadwaj Raju from comment #221) > The bug had multiple causes by which it could manifest. One cause was > tracked and *fixed* here. Other causes are tracked elsewhere as it is > easier. Is this concept really so difficult to understand? Correct, one of the causes was fixed, but that does NOT mean in any case that the bug has been fixed. If the error is still there, even if you have repaired 1 of all the causes, it means that it is NOT repaired.
CONFIRMED
Nothing to be seen here. Just move along. Don't waste your time and energy on trying to square the circle. Read up here: https://bugs.kde.org/show_bug.cgi?id=454345#c48