GNOME Bugzilla – Bug 537168
Playlist should follow/jump currently playing song
Last modified: 2009-07-02 09:39:27 UTC
Please describe the problem: earlier versions would center the playlist on currently playing track during shuffle mode, but this funcionality seems to be lost. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
Problem isn't fixed in Banshee-1 either. Steps: Create a larger playlist (more than one page), start playlist, fast forward tracks Result: Banshee doesn't focuses the actual playing track Expectation: Banshee should jump to playing track automatically (as in older versions) Does this happen every time: Yes; happens with and without randomizer, in freshly created playlists as well as in the main library Other info: Banshee 1.0.0 on OSS10.3 64bit
I can confirm using Banshee 1.0.1 (r4220). Changing status to new.
*** Bug 551964 has been marked as a duplicate of this bug. ***
*** Bug 551648 has been marked as a duplicate of this bug. ***
Ok, I think this should only be done if the currently selected song is the (previously) playing song, in order to not deselect songs selected manually by the user. So for the normal use case where you just double click a song you want to listen to, this would to The Right Thing, while for the not so common case that you select other songs without playing them directly (i.e. no double click), it would still respect the user's selection. Oh, and while I'm at it: if the currently playing song is not visible because of filters (album, artist, or search terms), the song that starts playing should be selected by default as well.
*** Bug 560899 has been marked as a duplicate of this bug. ***
*** Bug 560937 has been marked as a duplicate of this bug. ***
I have to add a "Me Too" to this one (and this also gets me on the CC list). I think there needs to be a preference box to "auto jump". I agree with Wouter too. In my use case, I leave it on random and in the background all day while working. Sometimes a song comes on that I don't want to listen to, but I *do* want to hear another by that same artist or off that album. So i have to open up banshee, then CTRL+J, then choose my new track. Kind of annoying. Related: I use the tray icon to "skip" all the time. It would be nice if there were another button next to [skip] that was [open] that would open up banshee, and do the CTRL+J automatically for me, centering the current track in the display list. Then I could just pick a new one and get on with my life. :)
Created attachment 136609 [details] [review] Follow the currently playing song A quick patch implementing what was suggested in comment #5. Please test it. Bug 522731 is related to this one. Actually, I fail to see why they are not duplicates. This patch should fix both of them.
*** Bug 522731 has been marked as a duplicate of this bug. ***
I like this approach, Alexander - very simple. I think we should add one more check (after your existing ones) to make sure the playing track is in view as well, and only jump to the new one if that's the case, to prevent this scenario: You've been listening to music, and Banshee has been jumping your list to the playing song, all is well, but then you start scrolling away but haven't changed the selection yet, the song changes, and you get jumped when you didn't want to be. If you agree, we'd probably want to add a helper method to ListView: IsRowVisible (int) (that itself could use GetRowAtY)
Created attachment 136790 [details] [review] Don't jump to the new track if previous track is not visible Gabriel, that makes perfect sense. Updated the patch to avoid jumps (but still change the selection) when the playing track is out of view.
The ListView_Model.cs changes concern me a bit. With the current code, you can select a song, and then as you search, assuming what is selected still matches, that code will ensure it stays in the view. It's not done perfectly, and maybe shouldn't be done at all - test it out, tell me what you think. We could put that code in the DatabaseSource's RateLimitedReload method.
(In reply to comment #13) > The ListView_Model.cs changes concern me a bit. With the current code, you can > select a song, and then as you search, assuming what is selected still matches, > that code will ensure it stays in the view. It's not done perfectly, and > maybe shouldn't be done at all - test it out, tell me what you think. > > We could put that code in the DatabaseSource's RateLimitedReload method. > The problem is that the model is reloaded whenever the next track starts playing. The removed code in ListView should only run when the filter is changed, not every time the model is reloaded. But the ListView has no idea what triggers the model reload. I hackish way could be checking the number of tracks in the model, if it's changed - the reload is caused by the filter. I will attach the patch. I'm not particularly fond of how it's done, but it works and I cannot think of an elegant solution that wouldn't be too bloated.
Created attachment 136887 [details] [review] Alternative patch
Ahh, right - so just move it into the FilterQuery setter - that's what I meant to suggest (so that it would only happen when the search changed).
Ok, I guess I hadn't thought that through all the way - that's what I get for sideline programming. :) Comment #16 isn't plausible since the DatabaseSource doesn't have reference to the ListView(s). Maybe you could move the code to BaseTrackList, and listen for/override the existing handler for model reloads, and when it happens, if source is DatabaseSource, see if its FilterQuery is changed?
Created attachment 136968 [details] [review] Keep selected tracks visible when the user searches (In reply to comment #17) > Maybe you could move the code to BaseTrackList, and listen for/override the > existing handler for model reloads, and when it happens, if source is > DatabaseSource, see if its FilterQuery is changed? The model doesn't have a (public) reference to the source, so we cannot access the FilterQuery property. Instead I'm using the DatabaseTrackListModel's UserQuery property.
Almost perfect! Trivial: can you cast as IFilterable instead of DatabaseTrackListModel to be more flexible A bit less trivial: It would be nice if the album/artist/[genre etc in the future] ListViews still did the center-on-selection thing that I asked you to move to BaseTrackList. Maybe we could add a ModelReloaded event to ListView, and then have a static helper class that can tack the center-on-selection functionality to any ListView by listening for that? In the case of the filter ListViews (album/artist/etc) we could maybe initialize that extra functionality in the FilteredListSourceContents, such that the artist/album ListViews get centered only if the main_view's model's query changed? Or maybe it should happen in TrackFilterListView.
I'm going to try to make the above changes.
Ok, I committed basically your patch but with the CenterOnSelection code pulled out into a protected ListView method. Thanks a lot Alexander, this is a really nice patch that a lot of users will appreciate.
Great to see my suggestons from comment 5 are implemented. Thanks a lot, guys.
Thanks Gabriel!