SUMMARY *** In a virtual machine (e.g. VMware), when OpenSUSE/KDE 15.4/5.24.4 is migrated to 15.5/5.27.4, if you had a global (non-resolution-specific) icon position configuration in your ~/.config/plasma..., it will be converted to a resolution-specific configuration, and then any resizing of the OS window will cause the icons to lose their positioning and get messed up. This didn't happen in 5.24.4, so it's a regression. *** STEPS TO REPRODUCE 1. Create a non-resolution-specific icon position cofiguration in KDE 5.24.x like: [Containments][1][General] ToolBoxButtonState=topcenter ToolBoxButtonX=728 iconSize=2 labelWidth=0 positions=6,27,desktop:/Firefox 24ESR,2,0,desktop:/kinfocenter.desktop,5,0,desktop:/Google Chrome,2,4,desktop:/Firefox 91ESR,2,3,desktop:/Firefox 68ESR,2,2,desktop:/XTerm,4,4,desktop:/Eclipse,1,0,desktop:/Office Free,5,3,desktop:/SuSE.desktop,5,2,desktop:/Support.desktop,5,1,desktop:/Firefox 78ESR,3,2,desktop:/Firefox 60ESR,3,1,desktop:/Firefox 45ESR,3,0,desktop:/OpenVPN,1,3,desktop:/VScode.desktop,1,2,desktop:/IntelliJ,1,1,desktop:/Firefox,3,3,desktop:/Konsole Green,4,3,desktop:/Amber Konsole,4,2,desktop:/XEmacs,4,1,desktop:/Firefox 52ESR,2,1,desktop:/Emacs,4,0 sortMode=-1 2. Upgrade to KDE 5.27.x. observe that positions is converted to something like: positions={"1801x1023":["6"\\,"28"\\,"desktop:/Amber Konsole"\\,"4"\\,"2"\\,"desktop:/Firefox 78ESR"\\,"3"\\,"2"\\,"desktop:/Konsole Green"\\,"4"\\,"3"\\,"desktop:/Emacs"\\,"4"\\,"0"\\,"desktop:/Firefox 102ESR"\\,"3"\\,"3"\\,"desktop:/Firefox 45ESR"\\,"3"\\,"0"\\,"desktop:/XEmacs"\\,"4"\\,"1"\\,"desktop:/Firefox 60ESR"\\,"3"\\,"1"\\,"desktop:/SuSE.desktop"\\,"5"\\,"2"\\,"desktop:/Firefox"\\,"3"\\,"4"\\,"desktop:/Firefox 115ESR"\\,"2"\\,"4"\\,"desktop:/Office Free"\\,"5"\\,"3"\\,"desktop:/Google Chrome"\\,"2"\\,"5"\\,"desktop:/Support.desktop"\\,"5"\\,"0"\\,"desktop:/Firefox 68ESR"\\,"2"\\,"2"\\,"desktop:/kinfocenter.desktop"\\,"5"\\,"1"\\,"desktop:/VScode.desktop"\\,"1"\\,"2"\\,"desktop:/Firefox 91ESR"\\,"2"\\,"3"\\,"desktop:/Twingate VPN Start.desktop"\\,"1"\\,"3"\\,"desktop:/Firefox 24ESR"\\,"2"\\,"0"\\,"desktop:/Eclipse"\\,"1"\\,"0"\\,"desktop:/Firefox 52ESR"\\,"2"\\,"1"\\,"desktop:/IntelliJ"\\,"1"\\,"1"\\,"desktop:/XTerm"\\,"4"\\,"4"]} which is resolution specific. 3. Now resize the VM guest window containing OpenSUSE OBSERVED RESULT If you change the window size by more than 40px or so, the icons that were formerly in a nice, hand-positioned grid will be skewed and messed up. You can "fix" the icons by reverting your resizing. EXPECTED RESULT Icon positions should be independent of the window size, at least as long as the window isn't made so small that the icons can't maintain their same position. SOFTWARE/OS VERSIONS: Windows: macOS: Linux/KDE Plasma: OpenSUSE 15.5, KDE 5.27.9 (available in About System) KDE Plasma Version: 5.27.9 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 ADDITIONAL INFORMATION Tried "locking" the icons. No effect. Supposedly, this new syntax should support a "*" size (i.e., instead of "1801x1023"), but that doesn't appear to work. Icons still get messed up when window is resized. Bug was observed originally in KDE 5.27.4, but persists in the updated system with the versions reported (KDE 5.27.9,...) This bug makes working with OpenSUSE in a VM guest more difficult.
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.