Re: [Rhythmbox-devel] How differcult is this bug?

[James Livingston <jrl ids org au>]

On 01/10/2005, at 9:47 PM, Martin Jeppesen wrote:

> I have wanted Bug 100552 to get fixed for a long time, so I will try
> fixing it myself =)
>
> Can anyone that knows Rhythmbox comment on the complexity of this bug,
> for someone like me that haven't hacked in Rhythmbox before? Easy,
> medium, hard?
>
> Bug 100552 is having an extra library to choose from.
> http://bugzilla.gnome.org/show_bug.cgi?id=100552


As per my comments on the bug, I think that adding a single extra 
library wouldn't be good, for three reasons:
1) Some people (such as myself) only want one library,
2) Other people may want more than two, and
3) For the people who want two, picking a good name is impossible. Your 
mention "Albums" and "Singles", but people categorise their music in 
different ways


The other two options are pretty much the same thing from a conceptual 
point of view - having multiple libraries doesn't really give you any 
useful functionality over using (automatic) playlists to divide your 
library up. From a implementation point of view they are different, 
however the only real difference the user sees at the moment is that 
playlists don't have browsers or a search box.

So the two options are adding support for multiple libraries, or adding 
browsers and a search box to playlists. I think that the latter would 
be easier, because the changes will be localist to the playlist source 
(and possible the library source, depending on how it's done), whereas 
adding support for multiple libraries would require touch a lot of RB 
to make everything understand them. One additional advantage of 
improving playlists is that even if we did support multiple libraries, 
quite a few people would want playlists to be improved anyway.


If we want to go the route of fixing bug 118862 (adding browsers and a 
search box to playlists), we need to consider how it affects normal 
(non-automatic) playlists. I'm not sure how easy it will be to deal 
with manual track ordering when only part of the playlist is visible - 
particularly the user re-ordering tracks.

I've though about how best to implement this before, because I was 
going to attempt it - but I never got around to doing it. I think that 
we should split the playlist source into two, rb-playlist-source and 
rb-automatic-playlist-source, because much of the playlists 
functionality only applied to one or the other - and it also lets us 
deal with normal playlists differently. The automatic playlist source 
could then either a) have browser and search box code copied from the 
library source included, or b) be derived from the library source, with 
modifications.

Option (a) would probably involve copy & pasting the browser and search 
box code, and merging it with the playlist code. This would probably be 
easier to tweak, but it would lead to a fair bit of code duplication.

Option (b) would probably be done by adding a new virtual method to the 
library source construct_base_query (or something), which is used to 
create the base query that the browser & search box criteria are added 
to. This would be called from the library source's construct_query 
function, with the default implementation being what the library source 
does now (create a new query with TYPE=X). The auto playlist source 
would override this, and return a copy of the playlist query. There 
would probably have to be some other modifications, but I don't know 
what they would be, until someone has tried it.


The above are just some ideas I'd though of, so there might be a might 
easier (and better) way of doing it. Hopefully it gives people some 
food-for-though anyway.


Cheers,

James "Doc" Livingston