Re: metadatabase

Kristian G. Kvilekval wrote:
> On Fri, 2003-10-17 at 11:09, David Hough wrote:
<snipped it all yea>
> 
>>As long as the vector type functionality (list_length, item_at, etc...) 
>>talked only about the unexpanded list there is no chance of the UI getting 
>>confused about how a particlur item is represnted in the base playlist. 
>>The implementation of the current_position functionality would have to 
>>change slightly to provide a way of talking about an item that is a child 
>>of another item(s).
> 
> 
> Yes. And that's the problem.. if we iterate through the list
> what should we see?  The player will be iterating the list as a tree,
> however we would like to manipulate it as a set of flat lists.
> 
> 
>>The implementation of the current_position dosn't really have to be too 
>>complictaed, it could easily represnt a tree path as a simple vector of 
>>indexes at each depth, e.g. a vector containing 1,2,3 would mean the 3rd 
>>child of the 2nd child of the 1st unexpanded item in the playlist. I don't 
>>think we really need something as complicated as a tree path iterator to 
>>represent this, not even internally. The only place where this might be 
>>useful is in the move_next and move_prev functions which should be 
>>relatively simple functions even when talking about a tree path.
>>
>>Has anyone else got any thoughts/ideas on this?
> 
> 
> I have come to about the same conclusions, but I think the functionality
> should be split.  
> 
> 1.  The base playlist is a simple list of URLs
> 2.  It should easily translatable to/from a list of strings
> 3.  Deep(recursive) playlists are trees 
> 4.  Both views are useful and needed.
> 
> So .. how about base playlist that is a simple vector (wrapper) of
> URLS and another class that understands recursive playlists.
> 
> The second would  be a tree view on the set of recursive playlists.
> Each node would be a base playlist.   Both the UI and the player
> would have some sort of default recursive playlist.  They would
> communicate using a path expressions (child indices).

I think i handle all of these issues with the code i posted in my last 
mail with a single simple class.


> Now some sticky UI problems.. I am editing a new playlist
> and I drag-n-drop an old playlist.. what was the selection and
> what should be dropped the playlist or the contents of the playlist?

You drag and drop the name of the list to the PlaylistManager which, if 
using my implimentation, simply inserts the playlist name in the 
position where you dropped it (either in the top level playlist or some 
sublist) and the members of that list get copied along with it.  At this 
point i think it's safe to say that your UI will be reading a pointer 
(preferrably const) returned from the playlist manager to give it it's 
playlist.  This is the final necessity required to make the playlist 
manager viable. You cant have the UI's copy of the playlist get out of 
sync with the playlist manager's and you cant have the UI operating 
directly on the playlist managers so it should be reading from a pointer 
handed to it by the playlist manager.

My implimentation is inheritly (too lazy for spell check) a tree.


List of Playlist objects, all that have the playlists member set to NULL 
are displayed as audio streams to the UI.  The ones that have playlists 
not set to null are sublists given by the URI accompanying them, so the 
URI is displayed as an expandable link if possible in the UI.  Clicking 
on this link or button or whatever simply dives into that vector of 
playlists objects.  so on and so on.


My code is a proof of concept, no checks on infinite recursion are done 
and i'm fairly sure i'm missing some minor details with copying the 
object and what not.  Anyway the idea seems sound and the code looks 
like it can be made to work rather easily.   Rendering it to the user is 
of course up to the implimentation, but at least in the backend things 
are being handled as they should be.





-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
Linux in the Boardroom; in the Front Office; & in the Server Room 
http://www.enterpriselinuxforum.com