Version: 2.0-SVN (using KDE 4.0.98) Installed from: Compiled From Sources Compiler: gcc 4.1.2 OS: Linux After an edit track details action from the collection browser, it folds to the top of the collection tree 'Local Collection'. When unfolding, one's place in the collection, from where the edit track details action was started, is lost.
I can confirm the focus on the position is lost (reset to default), after editing some track details.
See bug 164116. Because currently when doing certain edits of track details Amarok doesn't show the changes, e.g. editing artists, the collection is being forced to refresh, which involves collapsing the collection every time you make a change in track details. Yes, I realize this is annoying, it's a temporary workaround, and eventually the idea is for it to remember where you were before the update of the collection, but it hasn't been implemented yet.
So leave this as a bug I think. Solve the problems with editing the collection first (e.g. #166908), as these are far more serious than this one.
*** Bug 167264 has been marked as a duplicate of this bug. ***
This also shows up when copying tracks onto mtp device. Any action on collection browser shouldn't do that. It's an usability issue.
*** Bug 170549 has been marked as a duplicate of this bug. ***
We've just decided that the constant folding of the treeview (which happens in many cases) is a major usability issue, and must be fixed ASAP. Hence I am changing the priority to VHI.
Looking at this report again, I don't think it deserves VHI priority. It's not that critical after all.
*** Bug 175734 has been marked as a duplicate of this bug. ***
I can confirm this issue for 1.98 (KDE 4.1.3 (KDE 4.1.3) "release 63.3", KDE:KDE4:Factory:Desktop / openSUSE_11.0), and I think it *is* a major usability issue. I just started Amarok 2 for the first time and am not ready to import my settings from 1.4 yet. So I would have to set "show under various artists" for a lot of albums. This bug would then be really annoying and make the job quite tedious. (Apart from that: Amarok 2 looks really promising and I'll definitely become a fan as soon as some issues like this one have been cleared.) BTW: I don't see why the tree should be collapsed in the first place.
I do not think importing the 1.4 collection deletes it, but to be safe you can make a copy of ~/.kde/share/apps/amarok and import from there. Or what makes you "not ready" yet?
Yes, it's the fear of losing ratings, playlists etc. as I have put quite a lot of time in making everything fitting my needs. And I was under the impression that you are/someone is still working on the import stuff. Apart from that: Amarok 2 has not been officially released yet, so it's not really deemed ready for "production use". So from my perspective: testing is necessary, but without the risk of losing my data.
On opensuse kde3 and kde4 apps are kept separately, i.e. .kde and .kde4. And making a copy isn't that hard either.
This is going to be a bit too complicated to fix for 2.0.0, retargetting.
*** Bug 177597 has been marked as a duplicate of this bug. ***
I can confirm this occurs on OpenSuSE 11.1, KDE 4.1.3 "Release 4.9", with Amarok 2.0-SVN. I believe this should be a high priority issue.
SVN commit 901623 by mkossick: filter instead of reseting the the collection tree view whenever one of the collections emit the updated signal. Make sure that the various artists node is always at the top or bottom of the list Automatically expand the Various artists nodes after filtering too BUG: 166841 M +6 -0 CollectionSortFilterProxyModel.cpp M +3 -2 CollectionTreeItemModel.cpp M +52 -5 CollectionTreeItemModelBase.cpp M +3 -0 CollectionTreeItemModelBase.h M +16 -2 CollectionTreeView.cpp M +1 -0 CollectionTreeView.h M +2 -1 SingleCollectionTreeItemModel.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=901623
Thanks for your work! However, I think this bug should be reopened because the problem is not completely resolved. The tree doesn't fold anymore, but the place where you were in the collection view before editing the track details is not restored. It still scrolls up after track details are edited and the artist subtree is collapsed (I am sorting the collection by Artist/Year - Album). If you read the bug report you'll see this loose of context was the problem the reporter complained about. The refreshing of the collection was just part of the causes.
@Rafael: Yes, I can confirm this. It's better than it was before, but still not optimal. Reopening. PS: I'm not sure if it's technically possible to do this correctly. Others will have to decide about that.
Any news on this bug? No changes since January...
Still present in 2.2-SVN, r997463
This still happens in latest 2.2-git and is really annoying!
*** Bug 205692 has been marked as a duplicate of this bug. ***
*** Bug 206289 has been marked as a duplicate of this bug. ***
Fixed for 2.2-beta2