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

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.

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.


James "Doc" Livingston

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