Qt: 4.5.1
KDE: 4.2.70 (KDE 4.2.70 (KDE 4.3 >= 20090415))
kdelibs: r960298
kdebase: r960293

I switched to folder view, changed some icon positions and did align to grid and also tried lock in place. No problem till now but when I changed the icon size, the icons were sorted and my changes were lost.

*** Bug 210585 has been marked as a duplicate of this bug. ***

Created attachment 40077 [details]
Proposed patch

When enabling/disabling the previews, "needReload" should not be set to true, it is not really needed.... (the icons' size doesn't change)

However, as KFilePreviewGenerator will *force* a reload when disabling the previews (http://lxr.kde.org/source/KDE/kdelibs/kfile/kfilepreviewgenerator.cpp#1145), we need to manually save and restore the icons position after setting the previews to false.

(In reply to comment #3)
> Created an attachment (id=40077) [details]
> Proposed patch
> 
> When enabling/disabling the previews, "needReload" should not be set to true,
> it is not really needed.... (the icons' size doesn't change)
> 
> However, as KFilePreviewGenerator will *force* a reload when disabling the
> previews
> (http://lxr.kde.org/source/KDE/kdelibs/kfile/kfilepreviewgenerator.cpp#1145),
> we need to manually save and restore the icons position after setting the
> previews to false.

The patch looks good except for one thing; setIconPositionsData() should only be called before the folder is opened/reloaded. The reason for this is that the data is used in the next layout pass and is then cleared. If the folder isn't reloaded after this function is called, the data will stick around and be used the next time something causes the layout to be changed instead.

So in this case it should only be called when m_showPreviews is false.

Thanks for checking it. - Can I commit the updated version of the fix ?
Regards

(In reply to comment #5)
> Thanks for checking it. - Can I commit the updated version of the fix ?
> Regards

Sure, and thanks for looking into this issue.

Darn, I discovered a flaw...
Disabling/enabling plugins (without touching the previews enabled/disabled settings) also need a refresh in order to work .... :-\
May be I can think of another solution

Created attachment 40105 [details]
New proposed patch

Split up the handling of previews enabled/disabled and preview plugins (as the last one needs to manually a reload the view)

SVN commit 1078287 by darioandres:

- Preserve the icons' position when modifying the preview settings

CCBUG: 182712


 M  +36 -6     folderview.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1078287

SVN commit 1078289 by darioandres:

Backport to 4.4 of:
SVN commit 1078287 by darioandres:

- Preserve the icons' position when modifying the preview settings

CCBUG: 182712


 M  +36 -6     folderview.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1078289

and add an horizontal scroll bar to folder view, if I place my icons where I like and then resize the folder view the icons are shifted from where I placed. If them are blocked on site and unsorted and unordered this shouldn't happen

what is the status of this bug? i see a commited patch, is the problem solved now?

For the lack of feedback i suppose the last commits fixed the problem.

sorry, i have to reopen.

some things are fixed for me now, like "align to grid" and some other options do not re-layout my desktop unintentionally. thanks for that.

but there are still cases, where these bug does apply:
for example I make the icon-size smaller. in this case there is really no need to throw away my relative icon-position-grid. and even if I would make the icons larger, I think there are better ways to re-align the icons than do a complete re-layout.

and also to what H.H says, should be fine to add an horizontal scroll bar to folder view, if I place my icons where I like and then resize the folder view the icons are shifted from where I placed.
If them are blocked on site and unsorted and unordered this shouldn't happen

another problem: drag a file (move) from dolphin to desktop: all positions are lost, and the symbol is not placed at the position, where I dropped it (it is sorted in the newly sorted icon-list)

forgot to say, that this is now kde-4.5

comment #16 is not the same issue as this one (which is about changes due to configuration). please keep reports to precisely one topic at a time. thanks.

I'm not sure I have the same issue, so please let me know if I need to file a separate ticket.

I'm using the folderview activity on my desktop, and I noticed these strange things:
a, the file .kde/share/config/plasma-desktop-appletsrc have the savedPositions line, but it's not always reflects the actual position of the icons. Probably updated "lazily", but sometimes it's too lazy and doesn't get updated at all.
b, after logout/relogin, the icons go back to their default position, while the .kde/share/config/plasma-desktop-appletsrc contains the correct, saved position information, and the config file isn't updated until I move an icon; then (after a while) it will contain the default positions, except for the one I just moved.

(In reply to comment #19)

> b, after logout/relogin, the icons go back to their default position, while the
> .kde/share/config/plasma-desktop-appletsrc contains the correct, saved position
> information, and the config file isn't updated until I move an icon; then
> (after a while) it will contain the default positions, except for the one I
> just moved.

One more thing: if I point it to an empty folder and create a couple of text files using the GUI and scramble those icons, they seem to be able to retain their position.

*** This bug has been confirmed by popular vote. ***

Now let us recap.

https://bugs.kde.org/show_bug.cgi?id=182712#c16 could not be present as of 2010-08-21:the commit that fixed that behavior is dated 2008!

The icon size change leading to a loss of saved icon positions is another bug and will be fixed.

I am now on kde-4.8 and tried again to drag a file from dolphin to the desktop:

- the other icons keep their positions (good)
- the dropped icon is not visible, I have to press F5 to make it visible (bad)
- the dropped icon has not the position I dropped it to, but seems to use the first free position from top-left to bottom (bad)

@Ignat Semenov: I forgot to say, thanks for your current work on folderview!

OK, thank you for the fast reply :)

The icon is not visible, have to F5 - I couldn't reproduce it, maybe it's because you have a lot of icons filling up all the desktop space or something? Certain details are obviously missing here.

Icon positioned not where it's dropped - well, at the moment it's put in the first empty position, that's correct. Now let's see. You have the icons custom positioned, so you wish the dropped icon to stay where you dropped it. But if the icons are sorted, then maybe the user wants to keep them sorted even after the drop? We need a compromise here. he code change is pretty trivial anyway :)

Also, the commit that fixed that problem is dated Sep 17 2008, so you could not experience this in 2010 Maybe you've mixed smth up there in c#16? :) It just couldn't be, according to the Git logs.

my desktop only has a few icons. I tried dropping a second time now, this time the icon appeared 1-2 seconds later without refreshing manually. I also have such problems sometimes with dolphin (that items are not refreshed automatically, or much later than they should).

for the other problem in c#16: I don't think I have mixed smth up, and I cannot switch back now to reproduce, but perhaps that was a cornercase like the above problem.

I suggest to close this bug (but not forget the problem with drop positions), and I reopen when I find a method to reproduce folderview destroying icon positions again?

The bug can not be closed as it's about icons size change destroying the positions as well.

Now Dolphin is a separate component, it uses a different view, soit's unrelated here.

Please, which kde package version are you using? If you use a *buntu derivative, could you please specify the version of the "plasma-widget-folderview" package?

I use opensuse kde-4.8 packages, for example
kdebase4-workspace-4.8.0-1.1.x86_64

*** Bug 273761 has been marked as a duplicate of this bug. ***

*** Bug 244929 has been marked as a duplicate of this bug. ***

Added one more corner case:changing the desktop font in system settings.

Bug still exists in KDE 4.7.2 of openSUSE 12.1. Just about any small change randomly swaps icons with each other, making folder view close to unausable.

Wait wait. "Just about any small change randomly swaps icons with each other" - what do you mean? There used to be a problem which I fixed for 4.8.1 where sorting results were sometimes inconsistent because the names were not taken into account for making the comparison, and this problem was sometimes described as random icon positioning.

Now this bug is about the following:

When you have custom icon positions (i.e. drag some icons around on the desktop and the sorting becomes "unsorted"), then on certain configuration changes, such as  icon size change, font size change, plasma theme change, and probably some others, the custom icon positions would be lost.

This is absolutely logical if you think about it, as the view needs to relayout the icons using the new size hints. Moreover, some icons may end up outside of the view if e.g. the new icon size is greater than the old one, and fixing this is not as simple as it may seem. We are working on a solution.

Ignat, you are seeing this from a programmer's perspective: you analyse the code, think about which part might be causing the problem, and look at how that can be changed. I am looking at it fromt he user's perspective. Where the problem is and what the problem report is called are not really of interest.

The problem is that people expect icons to remain in their grid position. This is expected behaviour ever since Billy 95, or over 17 years. The folderview locates itself prior to that. So someone changes icon size. All the icons become smaller. People still expect them to keep their position in their grid, even though each grid cell is now smaller/bigger. It has worked in 1995, and everyone is eager for KDE to catch up... ;-)

Likewise for basically every other change. Custom icon positions are expected to remain in their grid location. The absolute screen location is of no interest. Even if the grid is turned off, relative loations are expected to remain. Even after icon size changes. Multiply all screen coordinates by 0.8 for a 20% icon size reduction if you want/need.

"The view needing to re-layout" is or isn't logical, it's useless for the user. Icons "ending up outside of the view" doesn't make sense, there are scrollbars for that which suddenly appear, and that would probably be preferable - user can then decide whether to move icons, put up with scrollbars, make the view bigger, whatever, but doesn't loose the previous layout work, which is the worst possible view behaviour and extremely irritating.

I've turned the views off on all my hosts becuse for me they are unusable. I retested this after upgrading to openSUSE 12.1 / KDE 4.7.2.

"The problem is that people expect icons to remain in their grid position.">>>>>>>>=totally approve

"The view needing to re-layout" is or isn't logical, it's useless for the user. Icons "ending up outside of the view" doesn't make sense, there are scrollbars for that which suddenly appear, and that would probably be preferable - user can then decide whether to move icons, put up with scrollbars, make the view bigger, whatever, but doesn't loose the previous layout work, which is the worst possible view behaviour and extremely irritating.>>>>>=totally approve, many thanks Volker Kuhlmann to be able to express also my thinking so well, the idea to add horizontal scrollbar to folderview sprung to me too, and I cannot understund why this isn't made until now. :-)
Ciao Pier

I'd like to add another problem to this, I hope it fits this bug.

First: I'm running KDE 4.8.3 on Debian Wheezy and I use 1 activity with a full-screen folder view, to have a "classic" desktop.

Without changing settings or anything, if there are too many icons on the desktop, when I reboot the icons don't keep their position on the grid but they get moved (without any sort that I can see) from their position and put one after the other from top left going down. With "too many icons" I'm not talking about a big amount of icons, just the equivalent of three full columns of icons at 1280x800.
I don't know what trigger this precisely, but the number of icons present seems the only explanation to me right now.

Do you use custom icon positions Iacopo? (i.e. drag icons manually to a certain position, whether "Align to grid" is on or off does not actually matter here)

Oh wait, that comment was for another bug, sorry. Actually, the last report from Iacopo Benesperi is for the bug https://bugs.kde.org/show_bug.cgi?id=265774

*** Bug 306629 has been marked as a duplicate of this bug. ***

> When you have custom icon positions (i.e. drag some icons around on the
> desktop and the sorting becomes "unsorted"), then on certain configuration
> changes, such as  icon size change, font size change, plasma theme change,
> and probably some others, the custom icon positions would be lost.
> 
> This is absolutely logical if you think about it, as the view needs to
> relayout the icons using the new size hints. [...]

This logic is flawed.  Whenever the user has manually moved some icons, no configuration change should _ever_ change the positions of these icons.  Do we want to automatically undo user actions?

The underlying problem of this bug is that the user can only get custom icon positions implicitly by setting "Sorting" to "Unsorted" and then moving his icons.  A better solution would be:
(1) let the user choose _either_ automatic _or_ manual arrangement;
(2) only when automatic arrangement is selected, let the user choose a particular layout (top to bottom etc.) and sorting order;
(3) when manual arrangement is selected, _never ever_ touch the icon positions.

Holger, it already works like that. If you drag some icons around, then folderview switches to "unsorted" automatically. Once you change the sorting strategy or the flow, folderview switched to the "sorted" mode the new sorting / flow settings are applied.

Now for the icon position loss on various view configuration changes. Imagine you have increased the number of text lines under icons, do you want the icon text to overlap the image of the icon below? Or if you change icon size like 2-3 fold, then some icons may end up being out of the view. This is a difficult problem that  requires a thorough analysis of all the possible corner cases, it can't be solved right on.

We can indeed classify the various reasons for icon position loss, like icon text related changes (global KDE font size or typeface change, number of text lines in folder view change), then icon size change, grid size change, etc., and handle them separately, in order to minimize the negative impact on the user. There is no generic solution for this problem.

> Holger, it already works like that. If you drag some icons around, then
> folderview switches to "unsorted" automatically. Once you change the sorting
> strategy or the flow, folderview switched to the "sorted" mode the new
> sorting / flow settings are applied.

That's what I said: it is implicit.  There is no indication for the user whether is icons are arranged automatically or not.  I think it would be better to have the user explicitly say "yes, please arrange my icons" or "no, don't touch them".

> Now for the icon position loss on various view configuration changes.
> Imagine you have increased the number of text lines under icons, do you want
> the icon text to overlap the image of the icon below? Or if you change icon
> size like 2-3 fold, then some icons may end up being out of the view. This
> is a difficult problem that  requires a thorough analysis of all the
> possible corner cases, it can't be solved right on.

I agree that it's not easy for automatic arrangement, but for manual arrangement, it is: don't touch the icons.  A user who chooses to arrange his icons manually _wants_ to do it on his own.  If the icons overlap, let them overlap.  If some get out of view, the user can use a scrollbar.

> We can indeed classify the various reasons for icon position loss, like icon
> text related changes (global KDE font size or typeface change, number of
> text lines in folder view change), then icon size change, grid size change,
> etc., and handle them separately, in order to minimize the negative impact
> on the user. There is no generic solution for this problem.

Well, there can be no generic solution, simply because no program can read the minds of its users.  For this reason, I would rather have a program that behaves predictably, rather than a program that tries to be semi-intelligent.

*** Bug 310595 has been marked as a duplicate of this bug. ***

Git commit f86bf88770cf2e3b6518ddbcb96990596b892d3f by Eike Hein.
Committed on 22/05/2013 at 03:22.
Pushed by hein into branch 'KDE/4.10'.

Preserve relative positions when changing icon size in containment case.

Icon positions are preserved by scaling the top-left coordinate pair
by the difference between the old and new grid sizes, or by recreating
the same logical column/row coordinate pair in the newly-calculated
grid if the align-to-grid option is enabled.

Icons that run out of bounds (or exceed the maximum column or row)
accumulate at the relevant screen edges. There is a precedent for
this behavior in the general align-to-grid code.

The left-to-right or right-to-left flow is taken into account when
scaling.

Smarter behaviors can be imagined as an optimization (e.g. identi-
fying groups of icons along screen edges and preserving their edge
alignment regardless of overall layout flow), but this simple scaling
implementation certainly beats throwing positions away altogether.

However, positions do still get thrown away in the non-containment
case - as the regular widget is capable of handling overflow via a
scrollbar, relayouting to exploit that felt better in practice.

M  +74   -9    plasma/applets/folderview/iconview.cpp
M  +1    -1    plasma/applets/folderview/iconview.h

http://commits.kde.org/kde-baseapps/f86bf88770cf2e3b6518ddbcb96990596b892d3f

Note that in addition to the above commit, I have recently fixed at least three different causes of loss of custom icon positions when modifying the Folder View config, moving icons while the config dialog is open, and changing the workspace theme. There may still be other problems lurking, but I hope it's getting increasingly rare for someone to use lose their carefully arranged icon positions. Cheers.

thank you! lately someone takes care of these very important issue :-)

I would be very happy, when these fixes would also apply for the non-containment (desktop?) case.  The case, when icons are out of sight, could be handled by taking the nearest free position for example? would be still better than losing all positions.

Yeah, would be nice ... I have to get back to some other stuff before feature freeze for now, but I'll think about what we can do there.

And for the QML port we can rethink things from the ground up to make handling position data a priority - IMHO this is simply a data loss problem and data shouldn't be lost without a good reason ...

Git commit c4a4efae68dc3bbb94fd67438853f6f50858d380 by Eike Hein.
Committed on 31/05/2013 at 21:33.
Pushed by hein into branch 'KDE/4.10'.

Don't throw away icon positions when changing the text color.

M  +1    -0    plasma/applets/folderview/folderview.cpp

http://commits.kde.org/kde-baseapps/c4a4efae68dc3bbb94fd67438853f6f50858d380

Git commit c0d0eadd0cbd7ffee3ea0a84cec2abf7609a5672 by Eike Hein.
Committed on 31/05/2013 at 21:33.
Pushed by hein into branch 'master'.

Don't throw away icon positions when changing the text color.

M  +1    -0    plasma/applets/folderview/folderview.cpp

http://commits.kde.org/kde-baseapps/c0d0eadd0cbd7ffee3ea0a84cec2abf7609a5672

Icons "auto magically" rearranging themselves is still happening.  I'm guessing I'm on KDE 4.13 ('rpm -qa | grep -i KDE' shows 4.11, 4.12 and 4.13 depending on the rpm).  I arranged my icons as I wanted, right-clicked the desktop, selected "Icons->Align to grid" and this worked nicely.  Also selected "Lock  in place" and couldn't move the icons.  Then I decided to a taskbar...  Even with "Lock in place" the icons auto-rearranged.

My first recommendation is that, in this/these situation(s), a warning be issued about re-arrangement with an option to cancel.  Second recommendation, make every effort to accommodate the change without changing the relative layout (shift the icons up/down/left/right, compress spacing, reduce icon size if "increase" wasn't the requested action) if possible and, third recommendation, produce an error message (and abandon the change) if this isn't possible.

In case the version specification is still ambiguous, I'm running a late version of  OpenSuse 13.1 (downloaded about a month before the 13.2 release).

Hello!

This bug report was filed for KDE Plasma 4, which reached end-of-support status in August 2015. KDE Plasma 5's desktop shell has been almost completely rewritten for better performance and usability, so it is likely that this bug has already been resolved in Plasma 5.

Accordingly, we hope you understand why we must close this bug report. If the issue described  here is still present in KDE Plasma 5.12 or later, please feel free to open a new ticket in the "plasmashell" product after reading https://community.kde.org/Get_Involved/Bug_Reporting

If you would like to get involved in KDE's bug triaging effort so that future mass bug closes like this are less likely, please read https://community.kde.org/Get_Involved#Bug_Triaging

Thanks for your understanding!

Nate Graham