Re: Custom Tree in MusicBrowser using XML

Hi David,

   I think I had a similar thoughts about how the tree would be
formed when I started the mdb.   In that model, the tree would have one
or two node types.  Each tree node would have an embedded url.
Some urls would be zinf specific, as you have done, or simply file's or
streams: 

zinf://artist
zinf://album?artist=foo
file:///some/place/song.ogg

To be more specific, the tree and and mdb would act together.
Mdb would be used to gather information about each node.
The tree would use the metadata collected to display the url's
correctly.

Currently, mdb has two main functions for querying, 
one for querying containers and one for querying metadata:

1.  readEntries (const string url, resultlist_t& results)
    --  Read a set of urls resulting from the query
     Currently it responds with a list of names but it instead should
     always return a valid url (zinf, stream, file, etc) 

    for example 
     readEntries("zinf://artist", result)  
                     return set of urls representing all  know artists
      zinf://album?artist="foo"
      zinf://album?artist=bar
     ...


2.  readMetadata (const string& url, Metadata& md) 
    -- Read the associated metadata of the url.
    For file url, we read the assoicated metadata from the file tags, 
    name, etc..   We could also use this interface for zinf style
    url.  For example the zinf url zinf://artist would
    have the follow metadata fields defined
    title "Artists"
    icon  "library"
    expandable "true"
    
Maybe the above was not as clear as I would like it to be, 
but I the point I am trying to make is the tree control
should deal only with url and the metadata associated with the 
URL.  The Mdb functionality already has some capabilities needed,
however it needs to be extended to handle a few top level special zinf
style urls.   We can expand the readMetadata functionality to return
metadata associated with containers (directories, zinf urls, playlists),

For example the top tree nodes would have the 
following URLs and metadata.  I've intermixed some readEntries calls
to show expands

zinf://   [ title = "", icon = "", expandable = "true" ] 
readEntries("zinf://", r)   //   read root list
 zinf://files  [ title = "My Music", icon ="library", expandable="true" ] 
 readEntries("zinf://files", r)   // Read local files zinf list
   zinf://url            [ title = "All Tracks", ...]
   zinf://url?artist=;   [ title = "Uncateforized tracks"
   zinf://album?artist=AAA;  [title = "AAA" 
     readEntries ( "zinf://album?artist=AAA;", r); // read albums of artist AAAA
      zinf://url?artist=AAA;album=A1    [ title = "A1", icon = "album", expandable=true]
      zinf://url?artist=AAA;album=B1    [ title = "B1", icon = "album", expandable=true]
     

 zinf://type=P;  [ title = "My Playlists" , .. ]
   file:///home/music/playlist.m3u  [ title = "playlist", icon..., expandable="true")
   readEntries("file:///home/music/playlist.m3u", r) 
        file:///home/music/AAA/album1/sng1.ogg 
        ...
 zinf://type=S;  [ title = "My streams", ... ] 
 cd://           [ title = "CD Audio", .... ] 

Similarly, we could add standard directories to the main zinf list as  
file:///home/music/AAA [ title = "AAA", icon="dir", expandable = "true", perm = 0666 ] 


Soo.. the idea is to make the tree simply query the mdb for title and
icon information.   Since each node would contain the expandable flag
to signal the tree whether the readEntries is a legal operation 
and whether to use a collapsible node in the tree.  Note also 
that we could do some fun stuff like have album icons pick up from 
album art using a metadata filter.  Have expandable playlists, etc...

I think this would solve the problem on having to specify each node
of the tree with an XML node.  We would still need some configurable
way to specify how the root node (zinf://) expands in the nodes
I listed above.  Maybe some symlinks under the ~/.zinf or again
a fragment of XML.  I think your xml fragment (template) might
be especially useful to specify the expansion of zinf urls.
  

So the tree would effectively need only one kind of node.  Each node
would be a url and would query the mdb for the metadata associated with 
the url in order to determine the display properties.   

Kris

On Sat, 2005-01-08 at 21:00 +0000, David Hough wrote:
> Hi,
> 
> I've been thinking about changing how the tree in the browser is  
> specified. At the moment its specified using a series of objects (e.g.  
> MyMusicInfo, ArtistInfo, etc.) which return each other as children. There  
> are quite a few of these as each type of item, or single node needs its  
> own class written for it. Also, of course, this means the structure of the  
> tree is hardcoded.
> 
> What I'm thinking of doing is ditching all the different classes for each  
> of the items in the tree, and having one or two generic classes, with the  
> properties and list structure specified by XML. This would in effect mean  
> it would be possible for people to define their tree stucture and  
> contents, instead of our current one size fits all single fixed tree  
> structure.
> 
> This is still at an early stage, and I'm just wondering what other people  
> think of the idea?
> 
> I've so far hacked together an implementation that can parse the following  
> XML to create the "My Music" node on the tree.
> I seriously doubt that this is the best way to represent the tree in XML,  
> anybody got any better ideas?
> 
> <node text='My Music' icon='zinf-music-library'>
>    <node text='All Tracks' icon='zinf-all-tracks'>
>      <list url='zinf://url?type=F'>
>        <template url='@@url@@' input='url' icon='zinf-track' />
>      </list>
>    </node>
>    <node text='Uncatogorized Tracks' icon='zinf-uncatagorised-tracks'>
>      <list url='zinf://url?artist=;type=F'>
>        <template url='@@url@@' input='url' icon='zinf-track' />
>      </list>
>    </node>
>    <list url='zinf://artist'>
>      <template url='zinf://album?artist=@@artist@@' input='artist'  
> icon='zinf-artist'>
>        <template url='zinf://url?artist=@@artist@@;album=@@album@@'  
> input='album' icon='zinf-album'>
>          <template url='@@url@@' input='url' icon='zinf-track' />
>        </template>"
>      </template>
>    </list>"
> </node>
> 
> The 'node' tags represent a single node on the tree with the specified  
> text and icon.
> The 'list' tags represent a list of nodes generated using the  
> readEntries(url) function in MusicDB.
> The 'template' tags specify how to generate each of the nodes in the list.  
> By having templates within templates you specify sublists.
> 
> One obvious problem with the above XML is that there is no way to specify  
> a directory in the tree as they have potentially infinate recursion, and  
> this requires you to specify a new template for each sub list. So how the  
> XML is written will definetly need changing, I'm just not sure how yet.
> 
> Anyway, what do people think?
> 
> Cheers,
> David
> 



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt