GTKMM Musicbrowser Update

Since I last mentioned my patch to re-write the musicbrowser in gtkmm, I 
have done quite a bit of work on it and it is now close to having the same 
functionality of the old one, things i can remember that still need doing 
are

- CD Support (it just has the cd icon with no children at the moment)
- Drag and Drop file support (you can move playlist entries using drag and 
drop, but thats it)
- Menu Bar and menu bar functionality - things like sort playlist and 
playback controls
- Store display options in preferences instead of hardcoded

The main functionality of the browser is working fine at the moment. You 
can import files, edit playlists, browser the library, etc. as i have 
implemented the toolbar and all its associated functionality, as well as 
obviously the library tree and playlist, etc.

I have also added some additional, optional, functionality. You can now not 
just display you're library in the tree, but also display an album list and 
track list, in a similar way to say winamp shows its library. For instance, 
if you click on an artist in the tree, all their albums would be displayed 
in the album list, and all their tracks in the track list.

The album and track lists are used to display additional information, e.g. 
track length, year, etc. as not much information is displayed in the tree.

I've also added tabbed playlists, so that more then one playlist can be 
edited without opening another music browser.

In relation to the previous discussion about the updated music catalog, 
I've designed the library tree so that it is generated on the fly, i.e. it 
dosen't read data about a rows children until a row is expanded. When a row 
is expanded the only information read is how many children it should have 
and that amount of rows is created. When a row becomes visible, by 
scrolling to it or whatever, data about that particular child is read, but 
not until that point.

This makes refreshing the tree extremely simple, as it just re-reads the 
currently visible rows, and when the other rows become visible again their 
data is simply read as if it had only just become visible. This means that 
events that change the library are treated exactly the same, so could 
easily be replaced by just the one catalog changed message.

To implement the tree in this way, I've separated out the specification of 
what the tree actually displays into a separate class. Each row has an 
associated cataloginfo class which has a generic interface that returns the 
metadata for that row, like how many children it has, its name, etc. To 
read data for a row, the tree calls the get_child function of the row's 
parent, and then reads information from the returned cataloginfo.

The tree treats all rows exactly the same, all the information about how to 
display things is stored in derived cataloginfo classes. For instance, "My 
Music", "My Playlists"..., are children of the CatalogRoot derived class. 
The my music child is a derived MyMusicInfo class that returns derived 
ArtistInfo classes. These derived classes deal with all the interface to 
the music catalog.

I've also tried to make sure each cataloginfo caches as little data as 
possible that can't be changed by a call to refresh_data(). e.g. the only 
information an artistinfo class needs is a name. It then reads the tracks 
for that artist when needed to return specific information, but not before. 
Hopefully this will mean that they can be easily changed to just storing 
urls as the new music catalog will require.

The technique of only reading metadata when a row becomes visible has also 
been used in the playlist list. This provides quite large performance 
increases when editing large playlists, at least a couple of seconds faster 
then the old music browser, and on some operations like removing large 
amounts of tracks can be over a minutes faster. Using playlists of about 
2000 tracks, I haven't been able to find an operation that takes longer 
then about 1 second.


Unfortunately I havn't got much time to dedicate to continuing this patch 
for a while, so unless someone else wants help out, there won't be much 
progress for a while I'm afraid.

The large patch is available at http://www-users.york.ac.uk/~djh123/ as 
well as instructions on how to get it to work. It no longer directly 
replaces the old musicbrowser ui, but creates a new one called 
musicbrowsermm, so to use it once its compiled you have to change your 
MusicBrowserUI preference to musicbrowsermm.ui


For some reason I couldn't access the cvs to check that patch was generated 
properly, but i have checked it against the arch cvsroot module

David
-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/


Message has been scanned by Webshield





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf