On Sun, 2005-12-18 at 00:42 +0000, Sam Thursfield wrote: > * One important thing I was going to implement is tagging. I know > tagging has turned into some kind of meaningless internet buzzword at > the moment but I have a few actual uses for it. Such as, sometimes I > have the urge to play guitar over records for a while. It's only > certain songs though and I thought the best solution is to tag these > songs with "guitar" or something. Then I simply filter for that tag > and my problem is solved. I'm sure there are some other good uses too > (perhaps it could be used instead of genres like on last.fm? Though > I'm not interested in this feature personally.) I have a couple of > songs I only listen to at Christmas as well. An xmas tag that I > filtered out for 50 weeks of the year would sort that out. So I think > they would be pretty useful. Sri Ramkrishna and I (and occasionally other people) have been discussing this recently, although we called it "personal categories" because "tagging" has other meanings in regards to music players. The technical side of it shouldn't be too difficult, but the big issue if the user interface. Sri and I tossed some ideas back and forward, but we couldn't really come up with a way of fitting it into Rhythmbox. For it to be of any use, there needs to be a convenient and nice way of setting and displaying categories/tags, that doesn't get in the way of people who don't want to use it. > How to implement this will take some thought. Initially I pictured > each song having its tags as children in a tree view of the playlist, > so they would be hidden until you clicked the expand arrow (maybe > shown for the playing song, etc.) . To edit them you could just double > click the text I suppose. I imagine this would be ass slow though > since the new GTK liststore/listview/treeview components are not > racehorses at the best of times. I guess it could just be another > column but by now I have a whole bunch of columns and they don't all > fit. I can't really think of a better way though. Editing could be in > the browser somewhere and stored... I guess in the rhythmbox db rather > than in the song itself. At least for now. Tag filtering is something > should obviously be placed in the browser somewhere. Two of the things that we did figure out, are that having a category browser (like the genre/artist/album ones) would be desirable and that putting categories info into a new column wouldn't work. Having a "expand" widget show more information, such as the categories, could work, and we could also make it show the information from columns the user has chosen not to be visible too. Tree views aren't that slow if you use "fixed height mode", which we have done for a few weeks; however I think that any kind of expanding would require turning it off, which would slow things down again. One idea that has just spring to mind is, instead of expanding the row, we could have a "selected song information" bar at the top/bottom of the track listing, which would display the categories for the currently selected track(s). Not sure if this would work or not, though. > * Another thing is tagging (or catagorising through some other method) > albums. I have some that are demos or bootlegs which I have in my > collection but don't actually want to listen to very often. The > obsessive compulsive in me maybe also wants to seperate singles, EP's > etc. Though I agree this is pretty pointless. I've though along these lines too. It would require making artists and albums first-class entities (at the moment they are just the strings from the tags), which might also make associating other data with the artist/albums easier too. > * Skipping songs is often crazily slow. While it's not mentioned in > bugzilla I don't think I imagine this is an issue that's being worked > on. Since it's not like I have an enourmous collection (<5000 songs) > and.. well I guess my computer isn't high end these days, but it > should be able to run a simple media player without hanging around. Most of the reason for the gap between songs (which makes skipping slow) is that gstreamer does some slow things when starting a song. This is *greatly* improved in GStreamer 0.10, and is virtually gapless. > * Sorting isn't as functional as I would like. I want to be able to > sort my library by artist, year and then track number. I'm sure > there's people who want to sort by a crazy combination of stuff. This > is actually an issue for me in more programs than just RB, so maybe > it's more a problem with gtklistview. The tracks are sorted according to a group of functions defined in rb-entry-view.c. In theory we could make it user-definable what sorting by a particular column means, however that would require some kind of funky "redefine sorting" dialog and the like. I'm not sure if we want to add that, or if there is a non-horrible UI for doing it. > * I don't like how the artist name and album are links to last.fm. The > first time I used them there was a song playing and on the spur of the > moment I decided I wanted to listen to the entire album. So I clicked > the button, thinking it would have the same effect as hunting for it > in the browser window, and instead a browser pops up and totally > throws me off. I appreciate the idea of having links to the last.fm > pages but I also really want to be able to browse to the current > artist/album without searching through a tiny listbox or typing the > whole name. Maybe we can solve this using a right click menu or > something. (and see also: > http://bugzilla.gnome.org/show_bug.cgi?id=317517 about last.fm links > for arbitrary songs) There seems to be lots of different ideas about what they should do. Personally I think we should either a) make the text not do anything, or b) make it pop up a "artist/album info" window, which can have lookup on last.fm/google music/wikipaedia/whatever buttons and a "browser this artist/album" button etc. > * I've seen some stuff about how the search box is a little flawed. > eg. if I'm after songs by the punk rock band X. If I type X into the > search box I'm going to get a couple more entries than I expected, > such as every band, album or song with an X in its name. However > something I realised is I could click on the artists list box in the > browser and press X and it should take me to that artist. What > actually happens is the whole thing freezes up but I take that to be > more a bug than a feature. It certainly shouldn't freeze; if you haven't already, can you file a bug about it? > * Since a tag editor is already in the works RB could be used to > import songs into my library. The current "import songs" is all messed > up I think. If I take the library listbox as a representation of the > library on disk, import songs throws that all off because now the > listbox has songs that aren't in my library on disk. I hope you get > what I mean from this heh. I guess it all depends on how you define "library". If you define it to mean the "organised music, not including the new unsorted stuff" then it probably doesn't make sense. If you define it to mean "everything that Rhythmbox knows about" it does. > Anyway this is not really my issue! It would be ace if I could take a > directory or a CD full of music, listen to it perhaps away from my > library to see if I like it, normalise it, tag it (manually, with > musicbrainz, however) and then move the files into my music library. > And perhaps tag them so I can remove them again easily if it turns out > I don't like them. I guess whether this should be included depends on > how broad RB's scope is supposed to be. I've recently been sorting out my "unsorted music" directory, which consists of a) deciding whether I want a particular track, b) tagging it and c) moving it to my main music directory. I'm doing this by importing the directory, and making a auto playbin that contains all the unsorted music. RB now has a "Move to Trash" command, which takes care of (a) as I can delete everything I don't want to keep. (b) mostly works, the only issue I've run across is that we don't have vorbis tagging yet. (c) is something that RB doesn't currently do. Although Rhythmbox now has the concept of the location of your library (for monitoring) it doesn't currently know how it is laid out. This will need to be added for cd-ripping anyway, so once we have that it shouldn't be too hard to add some kind of "move to main library" or "organise library" command. > * The little speaker icon (and its counterpart the no entry > sign) is mentioned in bugzilla here: > http://bugzilla.gnome.org/show_bug.cgi?id=144181 > Originally I thought it was a big waste of space and could be replaced > by just making the entry bold. (Though I seem to remember that's a > huge pain with a GTK listview for some reason.) Then I realised it > could be pretty useful for showing > a song's position in the queue, there's the little no entry sign, etc. > So I don't remember why I brought this up. Making the row bold isn't that hard (we do it for the source list). I think the column is useful for displaying a small piece of information, such as not being able to play the track. If we did make the entire row bold, it would make fixed-width columns (e.g. play count, time) a bit wider as well. Having an icon or number for enqueued tracks sounds like a good idea. > * A "jump to song" text entry/dialog. In XMMS sometimes I would decide > I wanted to a certain song so I would hit J, type enough of the name > to distinguish it from all the other songs and hit enter. I didn't > even need the screen to be on. The current search box really doesn't > satisfy this since I don't want to lose whatever subset of the library > I'm playing, I just want to jump to a song within it. If you want to choose the track by title, you can do this by selecting the entry view (e.g. clicking in it) and then typing - GtkTreeView's type-ahead searching does it automagically. If you want something more complex such as searching for an artist, or temporarily limiting the tracks lists this won't be enough. > * Ctrl+arrows would be better for skip than alt. First off that would > match Ctrl+space better. Second altgr doesn't work, it has to be left > alt, so it takes two hands to skip a song. Which is more annoying than > you'd think. We actually changed the keys from Ctrl-arrows to Alt-arrows not that long ago. The reasoning behind that was that Alt-arrows are the "recommended" keys for applications to use for next/forward and previous/back. This also lets people (who have the right kind of mouse) to bind the side buttons on their mouse to Alt-Left and Alt-Right and have it be next/previous in all their applications. > * A couple of other small UI tweaks: > - Toolbar buttons to go into small mode and fullscreen mode > - Panes between album, artist etc. in the browser > - Also it might be nice to change the browser setup (which boxes > it shows) via right click menu to save delving into preferences. These sound good. > - The "last played" field is silly, it should be a friendly date > like the ones in the the new GTK file select dialog etc. Seeing all > these 2005-12-17 is way too technical for a music player, I want > "yesterday" and "two days ago" etc. There is a patch to do this already in bugzilla, however it needs to have the string width calculation updated (because we use fixed-width columns). Cheers, James "Doc" Livingston -- "Zero Tolerance" in this case meaning "We're too stupid to be able to apply conscious thought on a case-by-case basis". -- Mike Sphar
Attachment:
signature.asc
Description: This is a digitally signed message part