https://bugs.kde.org/show_bug.cgi?id=360478
--- Comment #240 from tomash...@gmail.com --- (In reply to Uwe Dippel from comment #239) > Of course, it is possible, in case of decreased space, to add scroll bars. > So KDE is the first DE in history to add scroll bars to a start screen, > eventually? And when space increases, the icons are still hanging in the > upper left corner. No, they are not, positions of the icons are remembered when space increases - provided there has been such a resolution before. > And moving back from scare to original space, the scroll bars disappear? Yes. However, I too find scrollbars suboptimal (but still better than what is being done now). In commeny 237, I suggested a way to avoid scrollbars. However, when experimenting with it further, I think the behaviour should be as follows. 1. Unless manually moved, icons are always top aligned (this is the current state). User can change whether they are left-or right align (also current state). This sets "corner alignment". 2. When resolution changes, a test should be made whether each icon is still visible on screen. 3. If an icon is is visible and it has not been automatically moved in a previous resolution change, keep it. 4a. If an icon is is visible and it has been automatically moved in previous resolution, move it back 4b. If an icon is not visible, test whether there is a saved resolution with a saved position of this icon. 5a. If yes, place it to a saved position. 5b. If not, place the icon to the opposite cornet of the "alignment corner", starting with icons that are th furthest from the "alignmnet corner", respecting whether icons are sorted into columns or rows. The rationale: I think nobody wants icons to dissapper and most or all people want to keep placement of the icons as much as possible across different resolutions. As of now, when I move an icon in a given resolution and then change a resolution, that movement of the icon is reset. That is confusing and the above logic would solve this. I will try to illustrate it with a diagram. Lets have a 4x4 grid of icons. Numbers are positions, letters are icons: A B 3 4 C D 7 8 9 10 E 12 13 14 G H When the alignment is top left and into columns, transforming to 3x3 would yield this: A B G C D H 7 8 E (H and G went off screen, so they get automatically re-arranged, from bottom right corner, which is opposite to the "alignment corner", starting with H, which was the most "off screen"), number 9 is occupied, so it i placed on 8, then G on 7 - if there was another icon, it would have gone to 8 and 7). When the alignment is top left and into rows, transforming to 3x3 would yield this: A B 3 C D 6 G H E (the same as above, but now G and H are rearranged into rows, not columns) Now imagine we move icons as follows (from the previous example with rows): A B H C D E G 8 9 (so H and E were moved from 8 and 9 respecitvely to 3 and 6 - a property would need to be added tha would record whether placement is manual or automatic - only automatically placed icons would change place when going back to a higher resolution) Now going back to 4x4 would give: A B H 4 C D E 8 9 10 11 12 13 14 G 16 (note H and E staying i their place set in 3x3, but G is rearranged). An obvious question is what should happen when we have 4x4 grid and more than 16 icons. Actually, I think then a scrollbar is a good solution. Also, I played with the current implementation a bit more 1) When one changes Alignment in "Desktop folder settings > Icons", it behaves in funny ways. It seems to just flip X and Y coordinates. Previously, it would rearrange icons so they would all fit onto the screen. Now it happilly introduces scrollbars. I think it should behave according to the logic above using the property "manually|automatically" placed and should only change the position of automatically placed icons. Further, it should not just flip their x and Y coordinates, but fill them one by one onto the visible untaken-by-other-icons area starting from the alignmnet corner (roughly the behaviour before this patch). The more I think about it, the property "manually placed" is quite crucial. (In reply to Uwe Dippel from comment #239)a > There is light at the end of the tunnel, though: the project leaders have > obviously come to understand the underlying design flaw. So Plasma 6 will > surely solve this matter for good. Like with a full vector-oriented desktop. > Plus the option to store and retrieve multiple desktop arrangements, e.g. > for physically tiny screens like tablets, and large screens, like monitors. > E.g. with an applet similar to the one for switching activities. Has actually such a decision taken place or is it just wishful thinking? I am not sure if I detect sarcasm in the above paragraph or not, please do not take this as an attack, I truly do not understand. (In reply to Nick Stefanov from comment #238) > @tomash...@gmail.com > Can you give me the compiled patched file for I want to try this chabges a > few days? The compiled KDE desktop is 24 GB, I have no idea what to send you and if it would work. It being from compiled from source, I do not have any installation package or anything. -- You are receiving this mail because: You are watching all bug changes.
