headers
David Hough | 8 Jan 22:00

Custom Tree in MusicBrowser using XML

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>
(Continue reading)

Permalink | Reply | 501 comments |
headers
kristian kvilekval | 12 Jan 00:16
Picon
Gravatar

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
(Continue reading)

Permalink | Reply | 501 comments |
headers
David Hough | 13 Jan 20:01

Re: Custom Tree in MusicBrowser using XML


On Tue, 11 Jan 2005 15:16:10 -0800, kristian kvilekval <kris <at> cs.ucsb.edu>  
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="foo"
>       zinf://album?artist=bar
>      ...

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=foo
readEntires("zinf://artist", "year", result)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Antonio | 16 Jan 23:31
Picon

Zinf traslation to Spanish

Hi, I have found Zinf recently and I like it. I've
translate it to Spanish. I send here the .po file. I hope it will be
usefull.

If you want it I can translate future versions.

Bye and thanks.

-------------------------------------------------------
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
Permalink | Reply | 0 comments |
headers
David Hough | 22 Jan 18:58

Hosting Arch archive on Sourceforge

Hi,

I was just about to get around to cycling my Arch archive, and I  
remembered that Kristian had mentioned something about hosting the  
cvstrunk branch in the sourceforge project area. This would allow for  
everyone with CVS access, to also be able to commit to the cvstrunk Arch  
branch via the sourceforge shell servers. This would vastly simplify the  
process of keeping Arch development in sync with CVS development. It would  
also make it possible to make an Arch archive part of the zinf.org website.

If we were to do this, it would probably make sense to make all brances  
off the sourceforge hosted branch, as I would anticipate Kristian would no  
longer have a need to keep an up-to-date cvstrunk branch himself. So, now  
that I'm about to create a new 2005 archive anyway, it seems like a good  
time to rebranch everything, if needed, as well.

I don't know how feasible this is, there may well be all sorts of issues  
about this that could cause problems. So, is this an idea worth looking  
into? Would anyone have a problem with it?

Kristian - How far did you get with this? Is it viable?

Cheers,
David
--

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

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
(Continue reading)

Permalink | Reply | 9 comments |
headers
Kristian Kvilekval | 24 Jan 04:46
Picon
Gravatar

Re: Hosting Arch archive on Sourceforge

I got as far as creating an archive and committing to it.  This can work
for multiple users as long as we use group (zinf) write-able directories
and *everybody* sets there umask appropiately.  I have not played with
extensively, but I think it will work.

However, what I wanted to PQM patch-queue-manager for applying 
patches and ensuring at least some semblance of regression testing.
I made no progress on this.

You might want to play with the first solution (the archive on
sourceforge).  The only problem I forsee is that we will have
to use our web space also for our archive space and sourceforge
adds a quota to the web-storage.   I kept thinking they 
would eventually offer arch style archives, but I haven't
seen anything yet.

On Sat, 2005-01-22 at 17:58 +0000, David Hough wrote:
> Hi,
> 
> I was just about to get around to cycling my Arch archive, and I  
> remembered that Kristian had mentioned something about hosting the  
> cvstrunk branch in the sourceforge project area. This would allow for  
> everyone with CVS access, to also be able to commit to the cvstrunk Arch  
> branch via the sourceforge shell servers. This would vastly simplify the  
> process of keeping Arch development in sync with CVS development. It would  
> also make it possible to make an Arch archive part of the zinf.org website.
>
> If we were to do this, it would probably make sense to make all brances  
> off the sourceforge hosted branch, as I would anticipate Kristian would no  
> longer have a need to keep an up-to-date cvstrunk branch himself. So, now
(Continue reading)

Permalink | Reply | 8 comments |

Gmane