https://bugs.kde.org/show_bug.cgi?id=453141
Bug ID: 453141
Summary: When changing display resolutions, icons and widets
should try to keep the same position as much as
possible
Product: plasmashell
Version: master
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: Desktop Containment
Assignee: plasma-b...@kde.org
Reporter: tomash...@gmail.com
CC: notm...@gmail.com
Target Milestone: 1.0
This is a follow-up bug to https://bugs.kde.org/show_bug.cgi?id=360478
Previously, when changing resolutions, icons and widgets positioning would get
scrambled. Now, Plasma remembers layouts for each resolution, but that still
leaves two problems:
1) Icons still get scrambled once per new resolution.
2) When icon gets moved in one resolution, it is not moved in other
resolutions.
Therefore, I think the behvaiour when changing resolution should be modified
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.
3a. If an icon is is visible and it has not been automatically moved in a
previous resolution change, keep it where it is.
3b. If an icon is is visible and it has been automatically moved in previous
resolution, move it back where it was previously.
4. 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 that saved position.
5b. If not, place the icon to the opposite corner 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. The above logic would solve the current state when moving icon in
one resolution is not preserved into another resolution. 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|automatically placed" is quite crucial.
--
You are receiving this mail because:
You are watching all bug changes.
