Version: 2.1-SVN (using 4.2.67 (KDE 4.2.67 (KDE 4.3 >= 20090318)), Gentoo) Compiler: x86_64-pc-linux-gnu-gcc OS: Linux (x86_64) release 2.6.26-tuxonice hi, from of a usability point of view its quite annoying that the collection tree is redrawn from its root and doesn't scroll to the last selected entry after clearing a search condition. i noticed that the last expanded item is remembered, please make it scroll into view also.
Already fixed
Sorry, it's been fixed for the playlist, but not the collection browser.
ok, magnatunes browser has the same issue, don't know if this can be fixed at a central point
This happens also if you modify metadata starting from right-click on the collection browser. Once done with edits the view redraws to the top.
Any news on this? Still happens with 2.2-git
Fixed for 2.2-beta2
istn't fixed for me with current git, clearing still scrolls up to the root
nope, it's fixed. Tried this multiple in the local collection. Enter a search term, scroll down a bit (expand nodes if necessary), and then clear the filter. The viewpoint does not jump to the top. It looks like the servicebrowsers do not get this right, but this is another issue, and requires a more precise bug report.
this is a short screencapture showing that it doesn't scroll to the last selected entry after clearing a search condition in the local collection - not fixed for me http://hosting.aktionspotenzial.de/filepile/amarok.html
@max: i really do appreciate the efforts you put into this issue, but please leave this bug open as its not fixed, thanks.
Any news on this in Amarok 2.2.1?
Changing target.
Still not fixed in 2.4-GIT
Bumping version.
Making bug title more descriptive. When I have I'll look at this because collection browser behaviour bugs me too.
I would welcome a fix for this very much. For me it happens often that I search for an album I only know the name of a song of. Finding the song is easy, but in order to drag the album to the plalist, I have to clear the filter, and then I have to scroll a lot until I find the still open album again, or I have to remember its name and use the filter again to find it. No big deal, but still a little annoying.
Still not fixed in 2.6-git
This is ridiculous and shows perfectly the sad state amarok is in,postponing from version to version and even downgrading the severance,i'm fed up with that attitude
(In reply to comment #19) > This is ridiculous and shows perfectly the sad state amarok is in,postponing > from version to version and even downgrading the severance,i'm fed up with > that attitude Well, we do what we can with the number of developers we have and the time they have to work on Amarok. Remember that we all do this in our free time, and there are other bugs that are more important to solve first. You are of course very welcome to give a hand in development.
I have an idea how to approach fixing this without introducing another hack. Hopefully I'll find time to have a look at it before 2.8. When this is closed, also consider closing bug 176975.
I built Amarok from Git and imported a few albums. Then did exactly as shown in Simon's video and the focus goes back to the first item in the list, meaning it shows the very top of your local collection. Amarok Version: 2.7-git KDE Version: 4.10.3 "release 1" Qt Version: 4.8.4 Phonon Version: 4.6.0 Phonon Backend: GStreamer (4.6.2)
Confirmed on v2.8.0
Git commit 12884560c4bec1f94422385fc798a0fd921ba8fc by Matěj Laitl. Committed on 18/05/2014 at 09:34. Pushed by laitl into branch 'master'. Collection Browser: restore scroll location when the filter is cleared FEATURES: * Collection Browser scrolls back to its original position when the filter is cleared. FIXED-IN: 2.8.1 DIGEST: Amarok implements popular demand to restore scroll location when collection filter is cleared M +2 -0 ChangeLog M +1 -1 src/browsers/CollectionTreeItemModel.cpp M +25 -19 src/browsers/CollectionTreeItemModelBase.cpp M +12 -0 src/browsers/CollectionTreeItemModelBase.h M +75 -3 src/browsers/CollectionTreeView.cpp http://commits.kde.org/amarok/12884560c4bec1f94422385fc798a0fd921ba8fc
*** Bug 210721 has been marked as a duplicate of this bug. ***