GNOME Bugzilla – Bug 333904
Mouse click searching based on a song's metadata
Last modified: 2006-07-02 20:53:32 UTC
One usage example: Right clicking on one of a song's metadata fields (e.g the artist) should bring up an option to 'search for all songs by Arty Foo'. This would be much faster than the current requirement to type in the search box. Perhaps an extension of this would be to allow drag and drop of the fields to the search box (so dragging Queen to the search box would result in a search for all the songs by Queen).
It could be an extension where the user has two (or more options), such as: create a playlist with this artist/album/whatever" or just (as you proposal) filter the current view with such data.
Moving to the User Interface component.
Created attachment 64541 [details] [review] Proposal for searching by selected track's properties This patch adds a (context-)menu which lets the user to search for the same artist, album or genre as the current selected track. If there is more than one track selected the first one will get chosen. I had to add a getter method to the SearchEntry's Field property and I'm quite new to C# and Mono. So I don't know if its done the "right way".
Created attachment 64551 [details] [review] patch I just made a little change to my patch. IMHO it's better to first set the search type and then write the query into the search field (in my first patch I did it the other way round).
*** Bug 337551 has been marked as a duplicate of this bug. ***
My only issue with this patch: the items should only be on the context menu, not on the main banshee view menu as well. Go ahead and remove those and submit another patch...I think this is a good addition :) Also - I could not apply your patch; I had to do it by hand. Patch gave some crazy errors. I attached a new patch with the same code but works fine with `patch -p0 < thepatch.diff`
Created attachment 66691 [details] [review] Same as the last patch, but actually applies
Let's deprecate the old one then.
I don't know if removing this options from the View menu does comply with the Gnome HIG. Because AFAIK right click menus are so called undiscoverable features and therefore not easy to find for unexperienced users. But I agree that adding everything to the application menu clutters the UI. By the way, what is the correct way to build a patch? I thought I did it like it is recommended on the GnomeLove wiki.
I dont know much about the Gnome HIG, but it makes sense to me to have this on the right-click menu as that implies that you're performing an action (search by xxx for yyy) pertaining to the item you just right clicked on. Anyone else have any advice for this? As for the patch issue, I don't know what the deal is. Just doing a `cvs diff -u > this.patch` should do the trick. Patch was complaining about the line numbers being wrong, but it wasn't the usual error that you get when a hunk fails. I honestly have never seen that error before :)
Created attachment 67984 [details] [review] Updated patch I've removed the items from the view menu so that the filter options are only availabe through a track's context menu.
Marking this patch a little odd so I don't forget it :) I am cleaning up/committing my work over the past week from GUADEC and then will review this.
I'm committing a revised version of this patch. I moved the items to a sub-menu on the context menu to keep it from being so large. Also I added a private SearchTrackCriteria enum for SearchBySelectedTrack to remove the need for pointless private string object instantiations. Thanks!
Thanks, I like the enum solution. That motivates me to submit more patches.