Re: Custom Tree in MusicBrowser using XML

On Tue, 11 Jan 2005 15:16:10 -0800, kristian kvilekval <[email protected]>=
 =20
wrote:
...
> 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=3D"foo"
>       zinf://album?artist=3Dbar
>      ...

Returning URLs instead of actual metadata does sound like a good idea.
However, how does the readEntries function know which type of URLs to
respond with? Taking your example above, it returns URLs that
represent a list of albums. What if you want a URL that represents a
list of tracks by that artist, or however else the user wants to sort
the data?

For this to work I think readEntires needs an extra argument to
describe the list type.
e.g.
readEntries("zinf://artist", "album", result)
    zinf://album?artist=3Dfoo
readEntires("zinf://artist", "year", result)
    zinf://year?artist=3Dfoo

This method, unfortunately, requires the caller to know about multiple
levels of the tree. For instance, when you make the original call for
a list of artists, you need to know that the artists will be expanded
into albums

Instead, we could have the idea of generic URLs, whereby readEntries
returns a URL that specifies the arguments, but not how to expand
them. Then when you pass that url to read entries you specify what to
expand them into
e.g.
readEntries("zinf://", "artist", result)
    zinf://?artist=3Dfoo
readEntries("zinf://?artist=3Dfoo", "album", result)
    zinf://?artist=3Dfoo;album=3Dbar
readEntries("zinf://?artist=3Dfoo", "year", result)
    zinf://?artist=3Dfoo;year=3D2004

> 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"

Sounds extremely useful. The tree would no longer have to have
different ways to work out what text to display.

...

> For example the top tree nodes would have the
> following URLs and metadata.  I've intermixed some readEntries calls
> to show expands
>zinf://   [ title =3D "", icon =3D "", expandable =3D "true" ]
> readEntries("zinf://", r)   //   read root list

...

If the root of the tree is the URL zinf:// and expanded using
readEntries, presumably that means that the Mdb is then the place
where the structure of the tree is defined, correct?

If that is what you mean, I'm not sure thats really a good idea.
Firstly, this would mean that the core of Zinf defines how data is
organised and displayed to the user (even if it is a preference), when
surely this should be defined by whatever UI plugin the user is using
at the time?

Also, readEntries views the URLs in a tree out of context, so you
wouldn't be able to have a tree like:
zinf://artist
    zinf://album?artist=3D...
    ...
zinf://artist
    zinf://year?artist=3D...
    ...
Yes, this a rather unlikely example but hopefully it illustrates my
point. If the Mdb defined the structure of the tree, you would not be
able to have the same lists expanded differently in different parts of
the tree.

Going back to the possible redefinition of readEntries earlier, if the
tree structure was known to the UI instead, it would know the context
of the URL, and would then be able to tell the Mdb how to expand it.


> 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

Yes, this is pretty much what I was thinking. How the tree expands can
be defined in XML to give a user customisable tree, and the Mdb could
do the actual expansion and metadata handling. Then the tree is
suddenly very simple, with just the one node type, that has children
defined by the XML and metadata looked up via the Mdb.

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


-------------------------------------------------------
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