Bug 188074 - Clearing collection search scrolls back to incorrect position
Summary: Clearing collection search scrolls back to incorrect position
Status: RESOLVED FIXED
Alias: None
Product: amarok
Classification: Applications
Component: Collection Browser (show other bugs)
Version: 2.8.0
Platform: unspecified Linux
: NOR minor
Target Milestone: ---
Assignee: Amarok Developers
URL:
Keywords:
: 210721 (view as bug list)
Depends on: 300557
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-25 12:50 UTC by simon
Modified: 2014-07-26 23:58 UTC (History)
11 users (show)

See Also:
Latest Commit:
Version Fixed In: 2.8.1
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description simon 2009-03-25 12:50:40 UTC
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.
Comment 1 Seb Ruiz 2009-03-25 13:36:11 UTC
Already fixed
Comment 2 Seb Ruiz 2009-03-25 13:37:14 UTC
Sorry, it's been fixed for the playlist, but not the collection browser.
Comment 3 simon 2009-06-03 20:17:50 UTC
ok, magnatunes browser has the same issue, don't know if this can be fixed at a central point
Comment 4 Salvatore Brigaglia 2009-06-20 15:22:21 UTC
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.
Comment 5 Myriam Schweingruber 2009-08-02 15:14:34 UTC
Any news on this? Still happens with 2.2-git
Comment 6 Maximilian Kossick 2009-09-05 13:12:50 UTC
Fixed for 2.2-beta2
Comment 7 simon 2009-09-05 16:41:33 UTC
istn't fixed for me with current git, clearing still scrolls up to the root
Comment 8 Maximilian Kossick 2009-09-05 16:51:55 UTC
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.
Comment 9 simon 2009-09-06 12:17:24 UTC
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
Comment 10 simon 2009-09-07 12:05:42 UTC
@max: i really do appreciate the efforts you put into this issue, but please leave this bug open as its not fixed, thanks.
Comment 11 Myriam Schweingruber 2009-11-16 13:56:02 UTC
Any news on this in Amarok 2.2.1?
Comment 12 Myriam Schweingruber 2010-05-22 12:27:05 UTC
Changing target.
Comment 13 Samuel Brack 2010-12-07 16:21:28 UTC
Still not fixed in 2.4-GIT
Comment 14 Myriam Schweingruber 2010-12-07 19:58:39 UTC
Bumping version.
Comment 15 Myriam Schweingruber 2012-01-03 11:36:02 UTC
Bumping version.
Comment 16 Matěj Laitl 2012-02-02 20:44:42 UTC
Making bug title more descriptive. When I have I'll look at this because collection browser behaviour bugs me too.
Comment 17 Wonko 2012-07-03 15:32:03 UTC
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.
Comment 18 Mayank Madan 2012-11-30 13:08:05 UTC
Still not fixed in 2.6-git
Comment 19 simon 2012-12-01 10:19:17 UTC
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
Comment 20 Myriam Schweingruber 2012-12-01 11:41:40 UTC
(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.
Comment 21 Matěj Laitl 2013-05-25 09:58:42 UTC
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.
Comment 22 Ricardo Varas 2013-06-28 14:17:09 UTC
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)
Comment 23 Mikhail Ivchenko 2013-12-01 12:18:51 UTC
Confirmed on v2.8.0
Comment 24 Matěj Laitl 2014-05-18 11:21:28 UTC
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
Comment 25 Alan Ezust 2014-07-26 23:58:17 UTC
*** Bug 210721 has been marked as a duplicate of this bug. ***