Re: metadatabase

David Hough wrote:
> 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
> 

First off if you have a tree a flat view _does NOT make sense_. 
Branches off the tree could contain the same files as those in other 
branches and in the main tree itself.  This is confusing and serves no 
purpose at all. IF the person wants to see all the files at once, then 
this is simply a UI issue. All it needs to do is instead of creating a 
picture of the list that looks like the expanded view of a tree, to just 
not include the name of the branch (playlist name) and list all the 
files in a long list.  Again, i think doing that is utterly stupid and a 
step backwards from the whole point of having expandable playlists.

My implimentation has nothing that would make doing that difficult. If a 
for loop that ignores playlist names is a difficult concept then we must 
not be on the same page.


The point is to provide the tree, with absolutely no copies of the same 
data.  This object can get very large very fast given a complicated 
playlist and we dont want the player to start whoring ram simply to take 
the burden of different views from the UI to the playlistManager. 
Displaying the data in the player is the UI's job. That's what it does, 
and all it does.  My implimentation keeps all this data in a coherent 
manner that the UI can understand both from implication and clearly 
given values so it can take that data and render it any way it wants and 
still be able to be in sync with what the player actually has. All the 
while the size of the object only grows by the number of elements, 
instead of the number of elements * views you decide are necessary for 
the UI.



If you look at the mail i had with all the code included i think it's 
pretty obivous how everything can be handled in one simple class instead 
of having to regenerate things everytime you need them.




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