Restored trashed desktop files/folders are not returning to their correct (and available) placement on desktop.
Created attachment 175666 [details] Sometimes they're slightly wrong. Sometimes they just go the grid's first available corner.
This might have been fixed by https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/2603 I'm not sure.
Sorry, this one is that might be the fix for this: https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/2607
Nope, not fixed by that; I can still reproduce it. Conceptually I'm not sure it's cleanly possible to fix, though. Currently, when an item is removed from the desktop, we remove stored position information for it. If we didn't do this, the position information would grow infinitely, eventually consuming all space on the machine. The only way we could feasibly do this is if we recognize when an item was removed from the desktop *because it was moved to the trash* and preserve the position information for it while it's in the trash, only deleting the information once the trash is emptied. That might work. We would also need to handle edge cases like when another item has since been moved into the location that the trashed item previously occupied. What do you think, Akseli? Feasible or no?
Created attachment 175785 [details] Deleted files seem to have stored locations Then looks like I found another issue, since deleted files apparently have their positions stored, as you can test by Shift+Del a file, then move another file from somewhere else into the Desktop by moving into the Desktop folder, instead of drag and dropping on the area.
That's very interesting. But it's a different issue; please open a new Bugzilla ticket for it. Thanks!
(In reply to Nate Graham from comment #4) > Nope, not fixed by that; I can still reproduce it. > > Conceptually I'm not sure it's cleanly possible to fix, though. Currently, > when an item is removed from the desktop, we remove stored position > information for it. If we didn't do this, the position information would > grow infinitely, eventually consuming all space on the machine. > > The only way we could feasibly do this is if we recognize when an item was > removed from the desktop *because it was moved to the trash* and preserve > the position information for it while it's in the trash, only deleting the > information once the trash is emptied. That might work. We would also need > to handle edge cases like when another item has since been moved into the > location that the trashed item previously occupied. > > What do you think, Akseli? Feasible or no? There's a way to do it I think, but I am not sure if it will cause other problems.
Created attachment 175993 [details] All of the positions of deleted desktop files/folders are memorized. 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.
Deleted and trashed files/folders go through different codepaths. It looks like positions are correctly forgotten for trashed files, but not for deleted files. As such, *this* bug report is intentional per the comments earlier. Can you open a new one for the issue whereby deleted files/folders don't get their position data forgotten as intended? Thanks!
(In reply to Nate Graham from comment #9) > Deleted and trashed files/folders go through different codepaths. It looks > like positions are correctly forgotten for trashed files, but not for > deleted files. As such, *this* bug report is intentional per the comments > earlier. Can you open a new one for the issue whereby deleted files/folders > don't get their position data forgotten as intended? Thanks! Done. Bug 496556