Re: metadatabase

On Fri, 17 Oct 2003 20:21:51 -0400, Ed Sweetman <[email protected]> 
wrote:

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

As far as I can tell your implementation dosen't provide a simple way of 
viewing the entire expanded playlist as a single flat list which is a view 
that will be needed. Personally I think the list should be represented by 
a map of URLs with a tree path as the key, something like this quick 
example:

class Playlist {
	std::vector<std::string> base_list;
	std::map< std::vector<uint32_t>, std::string > expanded_list;
	
	void generate_expanded_list();
	void read_children(std::vector<uint32_t>& parent_path, 
std::vector<std::string>& urls);
};

The base list would be the list of original URLs for the playlist, and the 
expanded list would be a list of tracks that were expanded from the base 
list. This way you can do simple random access to tree by just reading the 
URL associated with a path from the map, and the playlist manager can move 
through the playlist using an iterator on the map.

The UI could read the base urls and then get specific children from the 
expanded list using the read_children function. This way the UI would 
always be in sync with the playlist as it would be reading the children 
directly from the playlists own expanded view.

This interface does provide both a tree view of the playlist and flat 
view. The flat view would just be the std::strings in the map, and the 
tree view is implemented by having a tree path asssociated with each url. 
I haven't got around to writing an example implementation of this class, 
but I would expect that the algorithms needed wouldn't be that 
complicated.

David

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


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