Re: [Rhythmbox-devel] thoughts on 0.5.2

Colin Walters <> writes:

> Scalability is my #1 concern right now.  I have an arch branch
> where I've been
> working on a new database backend, which is starting to pass some
> initial tests now.

Glad to hear.  I am not terribly familiar with arch but if you have
something ready for beta test I'll be happy to give it a try.

> Are you using 0.5.2?  There is a bug where it saves the library every
> minute or so, but this blocks the main thread, which can cause it to
> feel much less responsive.  That's fixed in the upcoming 0.5.3.

Yes, I'm using the Debian packages of 0.5.2.

> Ok.  The discussion about this is still ongoing.  I'm not very happy
> with how the notification area works.

What did you think of my suggestions for icon-click actions?

>> 4) Replay Gain support would be nice.  This is partially a gstreamer
>>    feature, but the controls need to be visible in the rhythmbox UI.
>>    See for details
>>    (their suggested dialog box is kind of cluttered, but gives you
>>    the idea).  Current xmms has this for ogg files and it's addictive.
> Yeah, there's an open bug about this:
> I can't say it's high priority for me.

This *might* be selfcontained enough that I could attempt it myself,
except I don't know anything about the gstreamer architecture.  Pointers?

> Hmmm.  I think I would rather have a better ability to manipulate
> playlists.  So you could easily manipulate a queue of songs to play.
> "play this track next" => drag it to be next in the playlist
> "stop at the end of this track" => drag it to the end of the playlist

These are nice and general but I'm not sure how one could possibly
make them work with a giant playlist.  Do you have any ideas?

> "never play this track again" => delete from library, you can always
> re-add it later if you change your mind

The trouble is finding it again in a 2000-track pile.

Maybe this should be handled through the rating system - shuffle play
ignores anything with a rating of 0, perhaps.

>> 6) I miss the ability to sort the library on multiple columns.  I'd
>>    like to tell it to sort first by artist, then by album, then by
>>    track.  Sorting by artist seems to do this but only by accident.
>>    I would also find sort-ignoring-leading-articles (a, an, the) useful.
> What would a UI for this look like?  Currently it does have hardcoded
> priorities for the different sort columns.

Good question.  The first thing that comes to mind is, you choose to
sort on a particular column by clicking on its header, so why not have
shift-click on another column mean 'and then sort by this one too'?

There might be something better, but this strikes me as workable and
discoverable, particularly if columns can be reordered.


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