After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 329984 - Type-ahead should work for any visible column
Type-ahead should work for any visible column
Status: RESOLVED FIXED
Product: rhythmbox
Classification: Other
Component: User Interface
HEAD
Other Linux
: Normal enhancement
: ---
Assigned To: RhythmBox Maintainers
RhythmBox Maintainers
: 543375 626356 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-02-05 10:37 UTC by Alex Lancaster
Modified: 2010-08-18 16:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
typeahead search patch (3.31 KB, patch)
2010-08-09 00:22 UTC, Scott J. Goldman
committed Details | Review

Description Alex Lancaster 2006-02-05 10:37:10 UTC
Currently type-ahead in the track list only works on the track (song) title column.  It should work on other visible columns.  e.g. I should be able to "type-ahead" on artist or album. 

Ideally this would work on which every column has focus.   iTunes does it this way.  But rhythmbox doesn't seem to set column focus per se, only row focus.  So there are several possibilities:

1. type-ahead on any visible column
2. type-ahead on which ever column is sorted
3. type-ahead on focussed column (would maybe require the concept of column focusing to be added, this would be a prerequisite for "live"-tag editing in any case such as that proposed in bug #326054)
Comment 1 James "Doc" Livingston 2006-02-05 11:52:02 UTC
I've thought about this before. There are some issues that we would need to think about:

* If you do want to search on the track name, it means you have to make sure you select the Track column, rather than just clicking somewhere in the track list. I think that wanting to search for track name would be *much* more common than others, because you can easily use the browsers/search box for artists or albums.

* There are some columns that it wouldn't make sense to do type-ahead finding on, should we search on Title if one of those are selected?
Comment 2 Alex Lancaster 2006-02-05 12:20:49 UTC
(In reply to comment #1)
> I've thought about this before. There are some issues that we would need to
> think about:
> 
> * If you do want to search on the track name, it means you have to make sure
> you select the Track column, rather than just clicking somewhere in the track
> list.

Right, that's the problem that it doesn't appear that there is an obvious signal to the user of which column is focused (can rb even deduce this at the moment?).

> I think that wanting to search for track name would be *much* more common
> than others, because you can easily use the browsers/search box for artists or
> albums.

True, but I often want to keep the full view of all the artists/albums but "jump" ahead to a particular artist in the list, while keeping view of all the other tracks.  (This is how I often use iTunes.) If you select an artist or album in the browser, then the view is immediately restricted to that artist/album.  

> * There are some columns that it wouldn't make sense to do type-ahead finding
> on, should we search on Title if one of those are selected?
 
If you choose option 1 that I gave above (on any visible column) then yes you'd ignore those ones, but choose the first one that matched any of the sensible columns.  For option 2 or 3 (either the sorted column or the column that had focus), then you'd have to choose a sensible one if it didn't appear to make sense to type-ahead on it.  I'll check how iTunes does it.
Comment 3 Jonathan Matthew 2008-07-18 10:27:31 UTC
*** Bug 543375 has been marked as a duplicate of this bug. ***
Comment 4 Jonathan Matthew 2010-08-08 11:59:50 UTC
*** Bug 626356 has been marked as a duplicate of this bug. ***
Comment 5 Scott J. Goldman 2010-08-09 00:22:18 UTC
Created attachment 167392 [details] [review]
typeahead search patch
Comment 6 Scott J. Goldman 2010-08-09 00:26:38 UTC
I implemented #2 as per the original dupe bug I filed. Jon reviewed and proposed an improved patch. I have attached my further improved (i hope!) patch which tries to minimize the work on the hot search patch a bit more.

If the user is sorting by a non-string column. It will fallback to search by title. This is consistent with the behavior of iTunes.

I am willing to refactor the patch based on review.

thanks.
-sjg
Comment 7 Scott J. Goldman 2010-08-10 03:06:18 UTC
Just to echo Alex's sentiments, and to elaborate a bit on why I think this is useful (not just cloning iTunes behavior for no reason): 

Usually I want to shuffle my whole library but first pick the initial song I want to start hearing. For whatever reason, my brain isn't really wired to select this track by song title. I look for the artist I want to hear, and then decide what song from there. Often after a few random songs I will pick a new song manually again.

For this reason, the artist/album browser is not especially useful to me. Once I pick an artist with the browser, I am no longer shuffling my whole library. Even if it was still shuffling my whole library, it's certainly a few more clicks to pick the artist browser, find the artist, then click the song. Simply keying in the first few letters of the artist i want, and clicking the song, seems more streamlined. This might seem trivial, but as I do this many times a day, the current typeahead behavior has begun to grate on me. 

Personally, I think using the sorted column makes the most sense here. If I am sorting by artist, I would consider that the index by which I am looking for a song. 

If you don't agree with me, I understand, but at the very least would you folks consider searching by title and artist rather than just by title? I can post a follow-up patch if this is the alternative that is decided upon.

thanks for building a great media player, guys!
-sjg
Comment 8 Jonathan Matthew 2010-08-18 06:08:01 UTC
I don't really know if this is the right approach.  I think the previous situation, as unhelpful as it was, was at least predictable.  With this change, I'm not sure we're providing enough feedback.  For a start, the highlight that's supposed to indicate the portion of the row matched the search string is always in the title column, even when we're searching something else.

Anyway, let's try it out and see what happens.  I've pushed this (with a few changes) as commit b9adba7.
Comment 9 Scott J. Goldman 2010-08-18 07:59:48 UTC
hmm... on my ubuntu 10.04 host (gtk 2.20.1 + ubuntu patches) the highlighting appears to sort of work, but only if the column sort indicator is properly set. seems like if you start rhythmbox, it remembers which column you sorted by, but doesn't display the indicator. in this state, i observe the nonsense highlighting behavior. if i click to sort by artist again, the little arrow indicator appears on the column, and then highlighting seems to works ok again. not sure yet if that's a gtk bug or rhythmbox bug? 

the behavior of this was always sort of weird. if you fail to match typeahead it starts highlighting random things. 

also, a potential further improvement (in the vein of what Doc had said above) maybe we might want to revert back to search by title if you do happen to use the album/artist browser.
Comment 10 Scott J. Goldman 2010-08-18 08:01:21 UTC
err, to clarify, functionally it's fine. the selection is always correct, just the highlighting to show what was matched is a bit wonky.
Comment 11 Jonathan Matthew 2010-08-18 08:31:40 UTC
I'm not sure what's wrong with the sort column indicator.  I'm sure I've fixed it at least once before.

I think making the search property depend on the browser selection would make it too technically complicated and too complex.  We have two methods of restricting the track list (browsers and search bar) and two ways of navigating the track list (scrolling and type-ahead search), and I think making them interact would be a bit much.
Comment 12 Scott J. Goldman 2010-08-18 16:47:18 UTC
ok. i don't use the browsers, so i don't have a very strong opinion :)