| Summary: | Positions of permanently deleted desktop files/folders are inappropriately retained | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Fernando M. Muniz <fernandommuniz> |
| Component: | Desktop icons & Folder View widget | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | akselmo, hein, nate |
| Priority: | NOR | ||
| Version First Reported In: | 6.2.3 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/plasma/plasma-desktop/-/commit/4fb8e8244b8f76a4b65b0d6d9ccc0821dc075f5c | Version Fixed In: | |
| Sentry Crash Report: | |||
| Attachments: | Shift+Del | ||
I can't reproduce this, it might have been fixed with https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/2641 Nate, can you test it again when you have time? 1. Create a folder to top left corner of desktop 2. Move it one column and row to right 3. Delete the folder with shift+del 4. Create folder again to top left corner of desktop For me the folder is in top left corner. Note that if you have a panel near, it will "push" the folder around since the panels margin may overlap with the icon grid. Unfortunately there's bad news: with yesterday's git master, I can still reproduce the issue with those steps. So it looks like it's not fixed yet. It's possible if you delete/create new very quickly, the saving process hasnt done anything yet. Will have to investigate further. I can reproduce this now, but only once per deletion and not every time either. I set a terminal to run `watch 'cat ~/.config/plasma-org.kde.plasma.desktop-appletsrc | grep positions'` and I see the position array being cleared properly. 1. Create a folder to top left corner of desktop 2. Move it one column and row to right 3. Delete the folder with shift+del 4. Create folder again from Dolphin in the desktop folder Sometimes it moves, sometimes it doesnt. I guess theres some cached information not being cleared properly. A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/2652 Can an exception be applied when a file of the exact same name is replaced on desktop? I personally think that having the file take the position of the replaced file is good design. Git commit 4fb8e8244b8f76a4b65b0d6d9ccc0821dc075f5c by Akseli Lahtinen. Committed on 03/12/2024 at 19:28. Pushed by akselmo into branch 'master'. positioner: Load position config after deferred moves When deferred moves are done for all the items, we should load the configuration afterwards to make sure any items on the configuration are placed in the correct place. Deferred moves often happen during folder view margin resizing or after folderitems loading/changing. Thus they can sometimes load unexpected positions (because they are looking for the best possible position for the item), even if the user has configured them to load in some specific way. M +3 -0 containments/desktop/plugins/folder/positioner.cpp https://invent.kde.org/plasma/plasma-desktop/-/commit/4fb8e8244b8f76a4b65b0d6d9ccc0821dc075f5c (In reply to Fernando M. Muniz from comment #6) > Can an exception be applied when a file of the exact same name is replaced > on desktop? > I personally think that having the file take the position of the replaced > file is good design. Unfortunately no, because like I explained in a different bug report, that would require keeping stale config data indefinitely, so the config file would only grow over time, and never shrink. (In reply to Nate Graham from comment #8) > (In reply to Fernando M. Muniz from comment #6) > > Can an exception be applied when a file of the exact same name is replaced > > on desktop? > > I personally think that having the file take the position of the replaced > > file is good design. > > Unfortunately no, because like I explained in a different bug report, that > would require keeping stale config data indefinitely, so the config file > would only grow over time, and never shrink. That's unfortunate. I hoped that the position data could be properly transferred over to the new file in situations of replacement. |
Created attachment 176019 [details] Shift+Del The new files are going to the expanded space of the desktop exactly where I had a file for the last time before I deleted it.