Re: [Rhythmbox-devel] A whole bunch of stuff

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 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 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
> 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:
> about 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 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

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:
> 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


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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]