Summary: | Single wildcard/all-resolution icon layout no longer supported - icons get messed up/moved when OS window is resized | ||
---|---|---|---|
Product: | [Plasma] plasmashell | Reporter: | spacemant5010 |
Component: | Folder | Assignee: | Plasma Bugs List <plasma-bugs> |
Status: | RESOLVED INTENTIONAL | ||
Severity: | normal | CC: | hein, nate, sollacea, tagwerk19 |
Priority: | NOR | ||
Version: | 5.27.4 | ||
Target Milestone: | 1.0 | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
spacemant5010
2024-01-01 11:00:58 UTC
Same issue on Manjaro/KDE physical machine. When the resolution changes, or rather I attach and remove an external monitor, the desktop icons get jumbled and I have to manually move them back into place. There doesn't seem to be any attempt made to remember or restore the original positions. They're just dumped into columns from left to right. Even ones that were already in the first column end up swapped around. Operating System: Manjaro Linux KDE Plasma Version: 5.27.10 KDE Frameworks Version: 5.113.0 Qt Version: 5.15.12 Kernel Version: 6.1.71-1-MANJARO (64-bit) Graphics Platform: Wayland Isn't this a classical instance separating "config" from "state"? You want to set up your machine in a specific way, you ought to be able to put that information in a config file It looks as if you are digging into "the last known state" and changing that. I'm sure I've read that this "separation" is something gradually happening (just where I read this, I don't know) but any gradual move in this direction is good... In the old days when icons regularly danced across the screen, I kept a copy of ~/.config/plasma-org.kde.plasma.desktop-appletsrc somewhere safe, ready to be copied back when needed It is, yes. Beyond that, I'm not sure there's a bug here. It's intentional that desktop icon positions are stored on a per-resolution basis now. This was done to solve many issues. It's known that the icon position behavior is still not great in a lot of cases, and icon positions can still get messed up. We're hoping to focus on that for Plasma 6.1 However until then, I'm afraid what you're seeing is intentional and unfortunately you'll just have to live with it until we can overhaul how this is done. You're not sure there's a bug? This is a regression from the KDE in OpenSUSE 15.4 seriously breaking workflow for everyone using KDE inside VMware or VirtualBox. Previously, the syntax for "positions" allows for a single layout for all resolutions. Now that declaration is rewritten into one with a specific resolution. Some sources say "*" for width should be supported with this syntax, but it's not. Why would anyone have intentionally broken single layout syntax? (One icon layout for all resolutions.) If that's a problem for some users, they can just use the resolution-specific syntax. VM users don't have an option, and now they're stuck with a crippled UI. This needs to be fixed! I've found a similar issue occurs when moving icons from one desktop to another. They get transposed onto a single line rather than keeping the intended layout. I have also found in some cases if you have icons on the far right of the display before switching, after rearranging the display will have a scrollbar as the icons get placed somewhere outside of the available grid. (In reply to spacemant5010 from comment #4) > Why would anyone have intentionally broken single layout syntax? (One icon > layout for all resolutions.) Because the concept of this doesn't make sense given that the resolution can change. When that happens, we have to re-layout the icons; if we don't save the positions per resolution, then the icons won't return to their prior positions when the resolution changes back to what it was before. We had tons ans tons of bug reports about this. @Sollace, those are unrelated separate bugs. (In reply to Nate Graham from comment #7) > (In reply to spacemant5010 from comment #4) > > Why would anyone have intentionally broken single layout syntax? (One icon > > layout for all resolutions.) > Because the concept of this doesn't make sense given that the resolution can > change. When that happens, we have to re-layout the icons; if we don't save > the positions per resolution, then the icons won't return to their prior > positions when the resolution changes back to what it was before. We had > tons ans tons of bug reports about this. In the previous release of KDE, used by OpenSUSE 15.4, no repositioning happened when the "resolution" (for VMs, the window width or height) changed. so there was nothing to be undone. So if the Eclipse icon was at location 100,100 from the top left, it just stayed at that offset regardless of "resolution." (In all the above, I'm assuming the window/screen is still large enough that the icon isn't off screen.) So, I must not be following something. Why do anything at all when the resolution changes? I think Windows 10 also does nothing in this case (as long as the icons aren't off screen) all. If you do nothing, there's nothing to undo when resolution "goes back." This is of course exactly what VM users want, because for them the actual pixel size isn't changing, they're just resizing their window, and there's no need to reposition anything. Imagine that you have an icon in the bottom right corner and then you reduce the resolution to something smaller. What happens to that icon? And then when you raise the resolution to what it was before, what happens to it again? (In reply to Nate Graham from comment #10) > Imagine that you have an icon in the bottom right corner and then you reduce > the resolution to something smaller. What happens to that icon? And then > when you raise the resolution to what it was before, what happens to it > again? You would be absolutely justified in doing whatever is necessary if icons are going to be clipped (positioned off screen) by a resolution change. Windows takes action in that case as well. However, that doesn't justify repositioning icons when not even one of them will be clipped by a resolution change. By analogy, if you had a house with a big plot of land, and the government decided to take a strip of your land away to widen the road, you'd expect them to tell you to move the detached garage next to the road, but you wouldn't expect that if your detached garage were already located far from the road, right? I'm not sure that metaphor applies to the current situation at all. The bottom line is that this is the way it's implemented intentionally, sorry. Changing it back would re-introduce multiple bugs that the current approach has solved. |