headers
David Hough | 22 Mar 00:17

XML Tree in MusicBrowser

Hi,

I've now got a working implementation of this, avaliable as the branch  
david <at> thepriorities.com--2005/zinf--xmltree, if anyone wants to play  
around with it. The Arch archive can be found  
http://www-users.york.ac.uk/~djh123/arch2005/

The default tree is represented by this snippet of XML:

<node text='My Music' icon='zinf-music-library'>
   <node text='All Tracks' icon='zinf-all-tracks' url='zinf://url?type=F' />
   <node text='Uncatogorized Tracks' icon='zinf-uncatagorised-tracks'  
url='zinf://url?artist=;type=F' />
   <list type='artist'>
     <list type='album'>
       <list type='url' />
     </list>
   </list>
</node>
<node text='My Playlists' icon='zinf-playlist'>
   <list url='file:///home/david/.zinf/playlists/' />
   <list url='zinf://url?type=P' />
</node>
<node text='My Streams' icon='zinf-stream-icon' url='zinf://url?type=S' />
<node text='CD Audio' icon='zinf-cd' url='cd://' />

Directory browsing is supported by simply adding a node with the correct  
url, e.g.
<node url='file:///home/david/mp3/' />
(Continue reading)

Permalink | Reply | 3 comments |
headers
David Hough | 28 Mar 17:33

MusicDB: Possible new implementation of readEntries(...)

Hi,

I've been looking at the implementation of the readEntries(...) function,  
and the current method of the MusicCollection class needing to know how to  
expand all URLs doesn't seem particularly extendable.

Instead I think we could have a system of multiple MusicListing sources  
which can expand different types of URL (e.g. one for zinf:// urls, one  
for file://*.m3u urls, etc.). The MusicCollection class would then pick  
the appropriate source to expand a URL and use that when readEntries(...)  
is called.

To deal with clashes where two or more MusicListing's think they can  
expand a URL, we could assign each source a priority and simply pick the  
single source with the highest priority. We could even make the priorities  
user definable similar to the way we want to define the priorities for the  
metadata sources.

Where it makes sense for a metadata source and a listing source to be  
implemented in the same class, e.g. the database, I see no reason why it  
couldn't simply implement the two interfaces MusicListing and MetadataDB.  
To avoid any confusion, it makes sense to make sure there are no clashes  
in function names between the two interfaces so I propose that the  
MusicListing interface would have the following 3 functions,

bool canExpand(url)
int getListingPriority()
void readEntries(url, entries) //Same as the readEntries function in  
MusicCollection
(Continue reading)

Permalink | Reply | 0 comments |

Gmane