Version: unspecified (using KDE 4.6.0) OS: Linux when I login I find my desktop icons resorted randomly. this happens not on every login but on maybe 4 out of 10, often enough to be annoying. Reproducible: Didn't try Steps to Reproduce: - use folderview as desktop view - arrange icons - logout, login again Actual Results: in roughly 40% of cases the icons resort themself, in what seems to be a random order Expected Results: icons should stay where i put them i have a rather huge wallpaper collection in one folder that is used for the slideshow wallpaper changer. I noticed that there seems to be a coincidence: whenever the icons rearrange themselves, the initial scan of that folder took longer than usual.
I have something similar I am using the folderview widget (version 1.0) it is set to sort icons by name (folders first) everytime I login, icons are scrambled. the settings is still set to sort by name with folders first. To fix it I have to set it to sort by something else (i.e. size), and then set it to sort by name again. Fixed until next login. It started a few weeks ago (I should have reported it straight away but I hoped that the developers would notice it themselves) I deleted the widget and placed it back to see if it was a problem with the configuration, but it did not help.
*** Bug 272716 has been marked as a duplicate of this bug. ***
Git commit 84a2cb8b818bd5386d8f54cf515d9ac43debc547 by Ignat Semenov. Committed on 09/02/2012 at 19:45. Pushed by isemenov into branch 'master'. when sorting files by category other than the name, and the data in that category is the same for both files, sort by the name instead fix sorting by size 1)If the files have identical size, type or modification time, sort them by name for consistency - this fixes "random" sorting 2)Explicitly handle sorting by size (previously done by size_t->string, resulting in wrong sorting) 3)When sorting by size, put folders on top of the list and sort them by the number of child items 4)Introduce three-level fallback for file name comparison, as done in Dolphin. Thanks goes to Peter Penz FIXED-IN:4.8.1 CCMAIL:peter.penz19@gmail.com REVIEW:103895 M +63 -10 plasma/applets/folderview/proxymodel.cpp http://commits.kde.org/kde-baseapps/84a2cb8b818bd5386d8f54cf515d9ac43debc547
Git commit ec55520721b71820bb4f928bf35f58f9b339ed14 by Ignat Semenov. Committed on 09/02/2012 at 19:45. Pushed by isemenov into branch 'KDE/4.8'. when sorting files by category other than the name, and the data in that category is the same for both files, sort by the name instead fix sorting by size 1)If the files have identical size, type or modification time, sort them by name for consistency - this fixes "random" sorting 2)Explicitly handle sorting by size (previously done by size_t->string, resulting in wrong sorting) 3)When sorting by size, put folders on top of the list and sort them by the number of child items 4)Introduce three-level fallback for file name comparison, as done in Dolphin. Thanks goes to Peter Penz FIXED-IN:4.8.1 CCMAIL:peter.penz19@gmail.com REVIEW:103895 M +63 -10 plasma/applets/folderview/proxymodel.cpp http://commits.kde.org/kde-baseapps/ec55520721b71820bb4f928bf35f58f9b339ed14
what if i do not want my desktop icons sorted at all because I arranged them to match my workflow? I have two user accounts on my laptop. the user account with $home on the local harddisk never gets hit by this bug. the user account which has $home on a nfs share from a fileserver gets hit by it a lot. this bug has actually been around much longer than since last year. please fix it.
Do you mean that you have custom icon positions, and these are sometimes lost after logging out and then back in? If that's the case, please specify how the icons are sorted after the bug happens? Do they maintain their custom positions, but in a different order, or are they all sorted and put one after another like if you chose to "Sort by Name" or other criteria? Please provide a screenshot before the bug (the state of your icons how you arranged them) and then a screenshot of the desktop after the bug happens. Thank you for reporting the issue.
you're aware that according to murphy you basically stopped it from happening for at least 8 weeks by asking for screenshots, right? :) anyway my normal way to arrange icons is in a group on the top left corner of my screen, grouped by purpose of the application. so I have a group of icons for folders, a group of icons for webbrowsers, a group for "other apps" like openoffice, moneyplex etc, then a group for software development apps, and then a group with games. When the rearranging bug hits, the icons get repositioned in one or more vertical rows across the full height of the screen, starting on the left side, but they aren't sorted by any order that I could determine.
OK, so this means that they are laid out automatically, and the custom positions are not taken into account. Indeed, they are not sorted in any way, because sorting is disabled in this mode. The icon view expects to be able to load custom icon positions and does not sort the icons explicitly - so they are most probably laid out in the directory listing order or smth else, quasi-random. Vertical rows on the left is the default flow for folderview when it acts as a containment, it's called "top to bottom, left to right."
*** Bug 295518 has been marked as a duplicate of this bug. ***
Git commit 808d4a3e65b387803ab2d6d278e77ef1bc108d0a by Ignat Semenov. Committed on 26/03/2012 at 16:05. Pushed by isemenov into branch 'KDE/4.8'. set the custom icon position data before setting the model This is to avoid a potential race condition between the end of the layouting process and setting the custom icon position data. M +4 -3 plasma/applets/folderview/folderview.cpp http://commits.kde.org/kde-baseapps/808d4a3e65b387803ab2d6d278e77ef1bc108d0a
Git commit 046c8cf4c6ed2549031018a8777aa2b34cdfdb57 by Ignat Semenov. Committed on 26/03/2012 at 16:05. Pushed by isemenov into branch 'master'. set the custom icon position data before setting the model This is to avoid a potential race condition between the end of the layouting process and setting the custom icon position data. M +4 -3 plasma/applets/folderview/folderview.cpp http://commits.kde.org/kde-baseapps/046c8cf4c6ed2549031018a8777aa2b34cdfdb57
Please, test the change in master. I do not have an NFS disk, so can not test the fix. Please report ASAP, I hope some of you are running master builds.
When the bug manifests itself, please, immediately after restarting plasma-desktop, copy and attach here the following file: ~/.kde4/share/config/plasma-desktop-appletsrc Also, please, make sure that this bug only occurs with unsorted icons. If the bug occurs with sorted icons (i.e. when Folderview sorting -> "Display" -> "Sorting" is set to "By name", "By date", "By type" or "By time", please, report it here.
Created attachment 70050 [details] the requested config file
By now the bug has taken a new shape: on login, all my icons are *gone*, and I have a scrollbar on the right edge of my screen that seems to indicate that my desktop resolution is actually about 100 times higher than my screen height. Actually using it to scroll around to "find" the icons does not help. I have to switch my desktop type to "Desktop" and then back to "Folder view" to get my icons back.
Thank you for the config. Now the scrollbar bug is 294795, it is well known, but I can't reproduce it.... would've fixed it a long time ago otherwise. I'm just waiting for a developer to encounter the bug or for a reliable way to reproduce it. OK, so from what I see in the config file, the icon positions are there, and they are at least sane. sortColumn is -1, which is how it should be, too. This confirms my ideas about the possible origin of the bug. To all the reporters: I've pushed a potential fix for this bug in 4.8.2, please, update to this version and see if the bug persists. Thank you in advance.
seems that either your fix hasn't made it into suse packages for some reason, or it's still not fixed, this morning I was greeted by my icons all out of place again.
Still a problem in KDE SC 4.8.2 from openSUSE build service.
I've just reproduced the bug in master. Wow, that's all I can say. Let's hope I can reproduce it enough times to be able to debug it.
Mathias, Can you confirm that *after* the bug occurs, the line savedIconPositions=*some text here* is present in ~/.kde4/share/config/plasma-desktop-appletsrc? That is, you log in, see that the custom icon positions are lost, and on the very same plasma-desktop run (*before* restarting plasma-desktop or logging out) look into the file mentioned above and check if the line is present.
Mine only has "savedPositions" (but I did manually restore the icons to the old positions after login).
Right, savedPositions, not savedIconPositions. What I'd like you to check is after starting plasma-desktop and finding out that the icon positions are lost, look for savedPositions in the config file, without dragging icons or restarting plasma-desktop once again.
Just had my icons rearranged on me again. lemmy@sai:~> grep -i positions ~/.kde4/share/config/plasma-desktop-appletsrc savedPositions=1,10,Documents,10,10,Work,10,134,kdevelop.desktop,212,134,firefox.desktop,111,10,chromium-browser.desktop,111,134,opera-browser.desktop,111,258,DolphinViewer3.desktop,313,10,Eclipse.desktop,212,258,startcenter.desktop,212,10,MoneyPlex.desktop,10,258 lemmy@sai:~>
*** Bug 298531 has been marked as a duplicate of this bug. ***
Hello, sme problem here, and it doesn't always happen. Flavio
KDE 4.8.3, still happening to me.
KDE 4.8.4, still happening.
It's happening to me, too (KDE 4.8.3 on Debian Wheezy). From what I've seen, it looks like this behaviour could be triggered by the amount of icons present on the desktop. for example, on my 1280x800 screen it never happened with 20-21 icons, while it happens when there are more. I don't know if it's only casual, though. Let me know how I can help.
@lacopo: I don't think so, it happens to me about half of the time, and I *always* have the same number of icons on my desktop... and 11 icons on 1680x1050 isn't that many.
(In reply to comment #28) > It's happening to me, too (KDE 4.8.3 on Debian Wheezy). > From what I've seen, it looks like this behaviour could be triggered by the > amount of icons present on the desktop. for example, on my 1280x800 screen > it never happened with 20-21 icons, while it happens when there are more. Yes! I've noticed that too!
Oh, you seem to be experiencing the bug as well Flavio? Expect a debug patch tomorrow. I've found quite a few places where the saved icon position data is cleared for some reason.. must be one of those.
(In reply to comment #31) > Oh, you seem to be experiencing the bug as well Flavio? Expect a debug > patch tomorrow. Thanks a lot! Yes, it seems I am experiencing the same bug.
I experience the same bug on Kubuntu 12.04 KDE 4.8.4. Even when I chose option "block/fix position". Perhaps this might be a part of a bigger problem which is: KDE reset settings to defaults like for example font settings or default program settings. http://www.kubuntuforums.net/showthread.php?59402-Kubuntu-keeps-reseting-default-browser-to-rekong-after-using-kdesudo http://www.kubuntuforums.net/showthread.php?56517-workaround-font-size-keeps-resetting
(In reply to comment #15) > By now the bug has taken a new shape: > > on login, all my icons are *gone*, and I have a scrollbar on the right edge > of my screen that seems to indicate that my desktop resolution is actually > about 100 times higher than my screen height. > Actually using it to scroll around to "find" the icons does not help. > > I have to switch my desktop type to "Desktop" and then back to "Folder view" > to get my icons back. I've got the same problem using KDE 4.8.4
Git commit 49e815d3c866ed6589e8cd0163eca0bd63490fd5 by Ignat Semenov. Committed on 13/07/2012 at 18:58. Pushed by isemenov into branch 'KDE/4.8'. only start the clear saved positions timer if it is already running M +3 -1 plasma/applets/folderview/iconview.cpp http://commits.kde.org/kde-baseapps/49e815d3c866ed6589e8cd0163eca0bd63490fd5
Git commit d3b8716c570f1f952c9d3718d94cfada8dcf94f9 by Ignat Semenov. Committed on 13/07/2012 at 18:58. Pushed by isemenov into branch 'KDE/4.9'. only start the clear saved positions timer if it is already running M +3 -1 plasma/applets/folderview/iconview.cpp http://commits.kde.org/kde-baseapps/d3b8716c570f1f952c9d3718d94cfada8dcf94f9
Git commit 8eef1f6d31e6a797f0418d1cdd0b3895ced8097d by Ignat Semenov. Committed on 13/07/2012 at 18:58. Pushed by isemenov into branch 'master'. only start the clear saved positions timer if it is already running M +3 -1 plasma/applets/folderview/iconview.cpp http://commits.kde.org/kde-baseapps/8eef1f6d31e6a797f0418d1cdd0b3895ced8097d
Please, check out master, if you can, and test this fix. In theory, this commit should have fixed the issue.
Ignat: is there a way to have a binary for x64 system of the patched file? I'd love to test this.
Iacopo, which system are you running? If necessary, I can provide a ppa for ubuntu.
I'm running Debian testing, I can download a single Ubuntu deb file, though. If you tell me which is the patched file (or files), I can even just replace that.
OK, I see, then I will build a patched .deb. Do you run 32 or 64 bit?
Patched file is the wrong way to do it, you may have different library versions and names, the .so I will send you simply won't load.
I run 64 bit. If you need to know the version of some of the libraries I use, just tell me.
Iacopo, can you use the project neon ppa's in Debian? Project Neon is a nightly build of the Ubuntu kde packages, it can be found on launchpad. The fix will of course go in 4.9, but before it hits your distro, you may be better off with testing the neon packages.
Do you think I can install just one package, the one containing the patched file? Are they still on kde 4.8.4? Installing just one package can be possible, not the whole DE. If you tell me the right file, I can even extract just that one file and replace it.
Project Neon is a daily build, that is, code is taken from trunk (master, daily snapshot) and compiled. I think one package will pull in the whole thing. If you wish to replace a single file, that is tricky, indeed. You may want to download the plasma-widget-folderview package from Neon and install it separately (bypassing your distro's high-level package management software, if I recall correctly, you should not be using apt, but rather deb or how it's called). Do that at your own risk, however. Major releases break binary compatibility, so the package may not work.
I see. Maybe the safest thing is to compile kde 4.8.4 on a VM with my same distro and take the needed file from there. In this case, can you tell me how I can pull the correct version of the source from git and give me the link to some info on how to compile it? I'm going to installa the VM right now.
The fastest solution for you is to setup an ubuntu VM and install project neon packages. This will be a few times faster and easier than compiling kde from source. Though this can take a bit of space, of course.
That's not the problem. The point is that I'm not sure that the bug will show up on the VM, so I prefer to copy a compiled file on my main system where I know that the bug happens. For example, this bus is present on my laptop but so far not on my desktop machine. So again, can you tell me how to pull the right source and point me some info on how to compile? I can afford to loose time anyway since I'm on vacation, so I prefer to compile kde on a VM.
Well, in that case you may try downloading the single package plasma-widget-folderview from Neon manually, then installing that instead of the existing package, while forcing your package manager not to resolve any dependencies (I think apt can do that). Or, you may indeed wait for the 4.8.5 / 4.9 updates, will those be ready anytime soon in Ubuntu do you know? The fix should be included in those packages. If you really wish to compile, then, if I recall correctly, on Ubuntu you can run the "get builddeps" apt command for the kde-baseapps package, then git clone git::/anongit.kde.org/kde-baseapps, cd to the source dir, and run cmake. But the best thing to do is install the Neon KDE packages. When you do that, a new session is automatically created, so you can continue using your old kde or the new one if you wish. If you have enough disk space, go for that, it will ensure the cleanest environment for the expirement. On Fri, Aug 3, 2012 at 12:04 AM, Iacopo Benesperi <registrazioni@iacchi.org> wrote: > Comment # 50 from Iacopo Benesperi > > That's not the problem. The point is that I'm not sure that the bug will > show > up on the VM, so I prefer to copy a compiled file on my main system where I > know that the bug happens. For example, this bus is present on my laptop but > so > far not on my desktop machine. > So again, can you tell me how to pull the right source and point me some > info > on how to compile? I can afford to loose time anyway since I'm on vacation, > so > I prefer to compile kde on a VM. > > ________________________________ > You are receiving this mail because: > > You are on the CC list for the bug.
Ok, so, I've compiled kde-baseapps (KDE/4.8 branch) inside the VM and then copied the file plasma_applet_folderview.so to my laptop installation, where I'm experiencing the bug. That should be enough to solve it, right? I'll let you know if it worked.
Well, if the VM has the KDE 4.8 packages, and you compiled against those, and your main desktop OS has KDE 4.8 as well, then yes, the file should work.
Actually, 4.9 packages are in the kubuntu backports ppa :) So you can as well simply upgrade the main os to those packages. Forgot to tell you about that, sorry.
The point is that I don't use Ubuntu, I use Debian, and you can't easily put Ubuntu packages inside Debian, not for something as big as KDE. Anyway, In the VM I use to build the corrected file I've installed the same distro I use in my laptop (Debian testing), which use KDE 4.8.4, so as you said it should work. The bug usually happens with a probability of 60-70% at each reboot, so I'll be able to tell you in the next few days if the bug is fixed for me or not.
@Ignat Can you tell me if this commit applies not only to places widget but also to the Desktop settings → Layout → Folder View? When I have this setting I have icons resorted randomlyn but I don't use "folder view" widget. Or maybe I should fill separate bug report?
You must be mixing up some concepts here, sorry. You can not have icons on the desktop without a folder view, apart from the built-in plasma Icon widgets, where every icon has its own widget handle. Do you mean that you don't have a standalone applet? Yews, the "folder view" desktop mode uses the same code as the standalone applet, this is the report about it. Are you still getting the problem after the commit? Are you sure you're using the right version?
Ignat: on my first boot this morning the icons were not resorted. It's too early to say anything but is good anyway. I have a problem, though: every time I open the context menu of a file in the desktop, either by right-clicking on it or with the keyboard key, plasma-desktop crashed and I have to re-run it. Does this depend on plasma_applet_folderview.so or maybe I should put on my laptop installation other files from the compiled version on the VM? And about the compiled version, I've pulled from the repo the last revision from branch KDE/4.8 because I wasn't able to tell git to pull/clone/checkout your revision 49e815d3 and not a newer one. Can this be a problem? Maybe the file this way is too new for KDE 4.8.4?
Well, crash is most probably from binary incompatibility. I know 4 crashes in folderview, 3 of them common, and this one does not belong to them. Latest revision is ok, I think that commit was the last one in folderview, actually.
binary incompatibility meaning? What can I do to fix that?
Probably nothing, actually.This means the version of a certain library mismatches between the machine where you compiled and the machine where you are running the code. Well, since this crash is irrelevant for this bug, we can happily ignore it :) Will Debian provide 4.9 anytime soon, do you know? AFAIK it is a rather slow distro.
No, it won't. AFAIK the current testing, which will become the new stable, will keep 4.8.4. Anyway the libraries used on the VM and the laptop are exactly the same, because I used the same repos for the packages and they're both up to date (I do a daily dist-upgrade), so it can't be caused by a library version mismatch, I'm sure of it. And anyway, even if it's not relevant for the bug, I have to use my system and I use context menu on desktop files, so I'd rather fix this. The only incompatibility that may arise is that the VM is on a PC with an Athlon 64 X2 while the laptop runs a Core 2 duo, but I've always installed packages compiled on one system in the other without problems. Do you think I should compile again with the Intel CPU?
Well, they both use x86_64, or AMD64, so this is fine. Once again, what actions preceded the crash? Could you post a "steps to reproduce" here? And a backtrace please. There is one crash where you right-click in a popup view (after you hover an icon, a popup icon view appears), is it that one? I'm fine with you posting it here, since it may be a simple incompatibilty, and I don't want to pollute BKO with one more BR. How is the topic bug going, any occurences yet? Thank you for the enthusiasm and help! See, I don't experience this bug here, the only way to gather data on it is to find a user like you. Wait, one more idea: on the VM where you compiled kde-baseapps, when you ran builddeps, are you sure it installed the 4.8 KDE development packages, not 4.9? Just in case. I'll try to ask some seasoned devs about this, report back later.
Oh, does the VM have a 64 bit debian installed? The CPU on that physical machine is 64 bit, but is the distro?
OK, the devs say you should recompile on an Intel, since the instruction sets are different.
The steps to reproduce are simple. I use folderview as desktop (as the whole desktop and not just a widget in part of it) and when I right-click on a file or folder on the desktop, either by first focusing on it with a left click of right-clicking directly on it. The crash happens also if I right-click on a file in a popup view of a folder on the desktop, but the popup itself shows correctly. The same happens if I press the keyboard key to open the context menu after focusing on a file. I'd be happy to give you a backtrace: where can I find it exactly? And yes, I'm sure there are no 4.9 packages in debian testing (nor in unstable so far, for what matters), just 4.8.4 ones. Yes, the VM is 64bit, too, of course. I'll recompile on Intel. About the subject of the bug: when I switched on the laptop this morning the bug didn't show up, but I've not yet rebooted again yet, so is a one-time check only so far.
Well the DrKonqui crash dialog should appear if any kde app crashes, are you seeing one after the crash? The BT is in the second tab in the dialog.
No, there's no DrKonqui window. Anyway, let's try to recompile with Intel first.
Ok, so: I've installed another VM on my laptop (so same CPU) and compiled again, but the crash with the context menu is still there. On the subject of the bug, everything's still fine after 3 reboots.
OK, read this techbase page: http://techbase.kde.org/Development/Tutorials/Debugging/How_to_create_useful_crash_reports I see you are a techie guy, so you should be able to figure that out :) In case you have any questions, feel free to ask me. Create a new bug report for the crash, product plasma, component folderview, severity crash, attach the backtrace when one is ready and we will sort that one out. Thank you for testing and reporting!
I've just found out once more that I'm an idiot and than I don't need to do a make install and put files around to have the .so file, so I've downloaded from git directly in my laptop installation and compiled there. The crash has disappeared (though I can't explain why it was present in the first instance, since the lib version is always been the same) and after another reboot even the bug didn't show up. I want to test it for a few days more before saying that the bug is fixed to me (it has happened before that it didn't show up for some days before reappearing again), but we're on the good way.
Ok, I think that now I'm ready to say that this bug is fixed for me.
Great! Now let's wait some time for people to report possible appearances of this bug in 4.9 and 4.8.5 (when those hit the repos) and close it. On Sun, Aug 12, 2012 at 2:44 PM, Iacopo Benesperi <registrazioni@iacchi.org> wrote: > Comment # 72 from Iacopo Benesperi > > Ok, I think that now I'm ready to say that this bug is fixed for me. > > ________________________________ > You are receiving this mail because: > > You are on the CC list for the bug.
Both versions, 4.8.5 and 4.9 are out since several weeks, closing as fixed.
Closing actually, sorry for the noise.
Iacopo, has the bug occurred for you since it has been marked as fixed? We have a new report here, which claims the bug still occurs in a recent KDE version, though the user is not quite positive about the version being 4.9.1 or older.
No, for me the bug is still fixed, of course with the file I've recompiled which contains the patch. Maybe the user has a version without your fix.
On Kubuntu 12.10 KDE 4.9.0 it is fixed.
It happened to me yesterday. I have KDE 4.9.1. If I lock the desktop closing the screen of the notebook and then I open it and insert the login password, often the kde panel freezes and I can't use KDE. I can click everywhere in the desktop but nothing happens. So, I killed plasma-desktop and restarted it with the command $plasma-desktop. At desktop restart, it appeared with the scroll bar on the right side. At startup it has never appeared till now. So the bug is not fixed!
The bug for the scrollbar is this one: https://bugs.kde.org/show_bug.cgi?id=294795 This is a different bug.
Luca, you seem to have mixed up the two bugs. If you observed a scrollbar on the right and no icons, that is #294795, and it is not yet fixed indeed. If the custom icon order was lost, then that is #265774, but it seems to be fixed now.