Version: 0.12.4a (using KDE KDE 3.4.0) Reported by Debian user Martin < e9525103 at stud4.tuwien.ac.at > (ref: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=330903) When I open an empty folder in the tree view or the file view k3b is visually busy endless (mouse cursor and progress bar in the file view). The functionality is not impaired. It is only confusing for the user.
Had the same behaviour with k3b 0.12.12 compiled from source. Deleting all k3b related files in ~/.kde/share/config/ (like k3brc) solved the problem for me.
Hmm, forget my comment above - the issue is back. Can't imagine why, because there was no problem yesterday. But if I select a empty folder, the mouse cursor changes to 'busy' and the progress-bar shows 0% . Nevertheless not a big issue.
i can confirm that this happens. The busy cursor is simply confusing - one is tempted to wait for it to finish when in fact it will stay in the busy state forever. Clicking on a non-empty dir makes it go away. However, using a "busy" cursor to click is very non-intuitive. The first time i happened to me i used Ctrl-Alt-Esc to kill k3b after waiting on it for several minutes (because it didn't occur to me that i would be able to click with the busy cursor). i'm using 0.12.10 (shipped with Suse 10.0)
I can confirm this bug for 0.12.17 built from Gentoo Packages.
I have no idea how to solve this. I already spent hours and hours on it without any success. :(
*** Bug 140742 has been marked as a duplicate of this bug. ***
*** Bug 143122 has been marked as a duplicate of this bug. ***
Confirmed on Kubuntu 6.10 on KDE 3.5.5, K3B 0.12.17.
*** Bug 148141 has been marked as a duplicate of this bug. ***
Now I see (vide duplicate) :-) The busy cursor is only when there is nothing to display (e.g. you set *.mp3 as filter and there is no mp3 file).
Confirmed for K3B 1.0.5 under KDE 3.5.10 "realease 21.9". Here, I can confirm Maciej's comment, it only happens when there are no files to display in the current foler. But the same beahviour with K3B 1.60.0 under KDE 4.2.1, where it is not related to an empty folder. Here, I always get a busy mouse pointer and a 100% progress bar in the folder view after starting K3B. Maybe it is of relevance, here I get a message about system configuration problems at startup and I have activated the "tip of the day".
The case described by Axel - it applies to k3b-1.66.0_alpha2 (on KDE 4.3.0) as well.
Deleting the k3brc file seems to solve the problem because the one that will be created upon first launch sets: last url[$e]=$HOME/ Now $HOME is kinda populated directory which is not affected by this busy pointer problem. There's something wrong with traversing the directories but the attitude is very complex. Hope to see this fixed soon. Tried on 4.3.2 with the latest k3b alpha. Note that this can be caused by something deeper than k3b like kdelibs, etc.
Created attachment 37619 [details] Patch to override the starting path to $HOME
I don't know if it was by coincidence *but* setting the lastUrl in src/k3bdiroperator.cpp to $HOME without reading the 'last url' entry in k3brc seemed to fix the problem at least for me. I've attached a workaround patch for that. Further testing is required to see if it really was the problem.
// CC to Michal Malek
@Ozan: Thanks for CC, I haven't noticed this bug before. I'm also experiencing this and it looks like a bug in KDirOperator (kdelibs). Your patch indeed workarounds the problem but it's not really a fix. I will try to find the issue in kdelibs.
Yes I know the patch is introducing a functionality regression, looking forward to a real solution, thanks :)
SVN commit 1049228 by mmalek: * Workaround for kdelibs bug: calling setUrl() right after setView() causes KDirOperator to show endlessly a busy cursor (and a progress bar) BUG: 113649 M +6 -5 k3bdiroperator.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1049228
@anyone who experienced this bug: please check if the above workaround fixes the problem for you. Nevertheless, it works for me
Confirmed to work, thanks. On the other hand, if it's really kdelibs bug I think it would be better to leave it exposed here for some time and push to fix kdelibs instead. Maybe CC kdelibs guys?
Yes, I'm going to make a simple test-case for this and report a bug against kdelibs.
*** Bug 216810 has been marked as a duplicate of this bug. ***
*** Bug 228305 has been marked as a duplicate of this bug. ***