headers
David Hough | 6 Apr 01:03

Re: XML Tree in MusicBrowser

Hi,

Just a quick update if anyone is interested. The definition of the tree is  
now a preference, and can be changed at run time using the editor found at  
"View -> Custom Tree...". The XML parser is hopefully much more error  
tolerent as well. So feel free to give it a whirl. If anyone wants some  
help with how to define trees, I'll be happy to help.

As to my other email ("Possible new implementation of readEntries(...)") I  
have now got a working implementation of this, which now provides support  
for CD listings in the tree again.

There are still things that need work, including re-adding the Edit  
Info/Remove pop-up menu items, so I won't be adding this to CVS quite yet  
unless anyone wants me too.

As mentioned below, its avaliable from the  
david <at> thepriorities.com--2005/zinf--xmltree Arch branch.

Cheers,
David

On Mon, 21 Mar 2005 23:17:28 -0000, David Hough <david <at> thepriorities.com>  
wrote:

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

Permalink | Reply | 2 comments |
headers
kristian kvilekval | 8 Apr 00:13
Picon
Gravatar

Re: XML Tree in MusicBrowser


Hi David,

   I finally got a chance to try out your new stuff.  
I think it's really cool that you've got this working.

I've got a couple of comments/questions.

1.  I think treemetadata is great.. 
1a. You should define string constants for all your 
    default strings (maybe in a toplevel file) i.e.
    const std::string kTrue = "1"
    which will help with insert and delete times.

2.  I also like musiclistings, but am wondering if
    we can provide the functionality in a single
    hierarchy.  For example mbcd and filemetadata
    could be improved to provide the readEntries function
    for urls that each of the modules can parse.  
    mbcd would take on expanding cd urls and filemetadata
    would do the playlist urls.

3.  It seems an opportune moment to try to integrate
    cachedb which should speed things up considerably.
    I am not sure if it was implemented correctly, but
    the idea was that once a deep metadata search had
    been performed, each metadata provider layer would be 
    given the chance to update its metadata.  In fact,
    the code is commented out at the 
     bottom of  MetadataPath::ReadMetadata
(Continue reading)

Permalink | Reply | 1 comment |
headers
kristian kvilekval | 8 Apr 00:22
Picon
Gravatar

genre browser


Dave does your new XML tree allow
one to browse by genre?

i.e. 

<node text='Genre' icon='zinf-Genre' url='zinf://genre' />
   <list type='url'>
   </list>
</node>

--

-- 
Kristian Kvilekval
kris <at> cs.ucsb.edu  http://www.cs.ucsb.edu/~kris w:805-893-2526 h:504-9756

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
Permalink | Reply | 3 comments |
headers
kristian kvilekval | 8 Apr 02:58
Picon
Gravatar

merge xml and browsermm


I think you need to merge 
your patches from zinf--browsermm patches 
dealing with string::size_type 

I ran into some problems with 64bits again,
but merging seemed to do the trick.

--

-- 
Kristian Kvilekval
kris <at> cs.ucsb.edu  http://www.cs.ucsb.edu/~kris w:805-893-2526 h:504-9756

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
Permalink | Reply | 3 comments |
headers
David Hough | 8 Apr 20:00

Re: genre browser

On Thu, 07 Apr 2005 23:22:08 +0100, kristian kvilekval <kris <at> cs.ucsb.edu>  
wrote:

>
> Dave does your new XML tree allow
> one to browse by genre?
>
> i.e.
>
> <node text='Genre' icon='zinf-Genre' url='zinf://genre' />
>    <list type='url'>
>    </list>
> </node>
>

Yeah, any valid url that the musicdb can understand is usable, so you can  
effectively sort by anything including genre. However the snippet you gave  
probably won't give the expected results as it's actually equivalent too,

<node text='Genre' icon='zinf-genre'>
	<list url='zinf://url' />
	<list url='zinf://genre' />
</node>

This is because when you specify a url for a node it checks if its  
expandable, and if so appends a child list with that url. If you just  
specify a type for a list whose parent is a node and not a list, it  
assumes you want a list of all those items, so converts it too  
"zinf://type", hence the url='zinf://url'.
(Continue reading)

Permalink | Reply | 2 comments |
headers
kristian kvilekval | 8 Apr 20:28
Picon
Gravatar

Re: genre browser


This line actually worked:

<node text='Genres' icon='zinf-music-library' url='zinf://genre'>

Could you explain or point me to the code how
"node" and "list" work?

On Fri, 2005-04-08 at 19:00 +0100, David Hough wrote:
> On Thu, 07 Apr 2005 23:22:08 +0100, kristian kvilekval <kris <at> cs.ucsb.edu>  
> wrote:
> 
> >
> > Dave does your new XML tree allow
> > one to browse by genre?
> >
> > i.e.
> >
> > <node text='Genre' icon='zinf-Genre' url='zinf://genre' />
> >    <list type='url'>
> >    </list>
> > </node>
> >
> 
> Yeah, any valid url that the musicdb can understand is usable, so you can  
> effectively sort by anything including genre. However the snippet you gave  
> probably won't give the expected results as it's actually equivalent too,
> 
> <node text='Genre' icon='zinf-genre'>
> 	<list url='zinf://url' />
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Hough | 8 Apr 21:44

Re: genre browser

On Fri, 08 Apr 2005 19:28:07 +0100, kristian kvilekval <kris <at> cs.ucsb.edu>  
wrote:

>
> This line actually worked:
>
> <node text='Genres' icon='zinf-music-library' url='zinf://genre'>
>
> Could you explain or point me to the code how
> "node" and "list" work?
>

Ok, I'll have a go.

"node" represents a single item on the tree (implmented using the TreeNode  
class in ui/musicbrowsermm/src/items/treeitem.cpp), and has 3 properties  
and a list of children (if any) which are
	- text
	- icon
	- url
None or all of these can be specified. Where a url is set it's metadata  
will be used for text and icon unless already set by the XML. If a url is  
set and it is expandable, the node will append a new "list" with that url  
to it's list of children.

"list" represents a generated list of "node"s (implemented using the  
TreeList class in ui/musicbrowsermm/src/items/treeitem.cpp). When the tree  
is displayed, the generated children of a list appear to be the children  
of the "list"s parent "node", so the list object itself is not shown  
directly. It has 2 properties
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Hough | 8 Apr 21:55

Re: XML Tree in MusicBrowser

On Thu, 07 Apr 2005 23:13:41 +0100, kristian kvilekval <kris <at> cs.ucsb.edu>  
wrote:

>
> Hi David,
>
>    I finally got a chance to try out your new stuff.
> I think it's really cool that you've got this working.
>
> I've got a couple of comments/questions.
>
> 1.  I think treemetadata is great..
> 1a. You should define string constants for all your
>     default strings (maybe in a toplevel file) i.e.
>     const std::string kTrue = "1"
>     which will help with insert and delete times.

Will try and look into it this weekend.

> 2.  I also like musiclistings, but am wondering if
>     we can provide the functionality in a single
>     hierarchy.  For example mbcd and filemetadata
>     could be improved to provide the readEntries function
>     for urls that each of the modules can parse.
>     mbcd would take on expanding cd urls and filemetadata
>     would do the playlist urls.

Sounds reasonable, I'd forgoten about mbcd when I created the cdlisting  
class. I think we might want to rename filemetadatadb to filedatadb if we  
do this though, as the contents of a playlist arn't really the files
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Hough | 11 Apr 21:47

Re: merge xml and browsermm

On Fri, 08 Apr 2005 01:58:22 +0100, kristian kvilekval <kris <at> cs.ucsb.edu>  
wrote:

>
> I think you need to merge
> your patches from zinf--browsermm patches
> dealing with string::size_type
>
> I ran into some problems with 64bits again,
> but merging seemed to do the trick.

Ok, finally done this. I've also made TreeMetadata use two new Metadata  
const's kTrue = "1", and kFalse = "0" for indicating expandable and  
playable flags

Cheers,
David
--

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

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
Permalink | Reply | 2 comments |
headers
kristian kvilekval | 11 Apr 23:07
Picon
Gravatar

Re: merge xml and browsermm

David,

I've setup a new archive and made some minimal changes
to ensure we can merge back and forth.

tla register-archive kris <at> cs.ucsb.edu--2005   http://www.cs.ucsb.edu/~kris/archive-pub05

I've made a branch of your xmltree called
zinf--xmlmod--0.2 and I'll be updating the mdb code there.

Could you try merging with my archive?

A question:

   Opening the first expandable element is pretty slow on my machine.
It looks like you need to extract the entire database.  Is there
a way we can look up only the visible data?

On Mon, 2005-04-11 at 20:47 +0100, David Hough wrote:
> On Fri, 08 Apr 2005 01:58:22 +0100, kristian kvilekval <kris <at> cs.ucsb.edu>  
> wrote:
> 
> >
> > I think you need to merge
> > your patches from zinf--browsermm patches
> > dealing with string::size_type
> >
> > I ran into some problems with 64bits again,
> > but merging seemed to do the trick.
>
(Continue reading)

Permalink | Reply | 1 comment |

Gmane