recusrive playlists was Re: metadatabase

On Fri, 2003-10-17 at 11:09, David Hough wrote:
> On Wed, 15 Oct 2003 12:44:38 -0700, Kristian G. Kvilekval 
> <[email protected]> wrote:
> 
> > On Wed, 2003-10-15 at 13:22, David Hough wrote:
> >> On Wed, 15 Oct 2003 10:37:00 -0700, Kristian Kvilekval 
> >> <[email protected]>
> >> wrote:
> >>
> >> > On Wed, 2003-10-15 at 10:18, David Hough wrote:
> >> ...

[snipped]

> This got me thinking exactly what functionality the 
> browser/playlist-editor actually needs from any playlist interface and 
> what functionality the base player needs. So I thought I'd have a go at 
> setting down the minimum requirements for any playlist interface.
> 
> Internally the base player surely only needs these public interfaces:
> 
> get_current_track
> move_to_next_track
> move_to_previous_track

These are actually special functions in the player as they 
need to take into account the repeat and play(random) modes.

The list has some predefined order like a vector (or depth first search
on tree).


> That is it, all other functionality is purely for the UI to manipulate the 
> interface.
> 
> In terms of just a playlist object (ignoring the handling of multiple 
> playlists, metadata, sorting, and loading/saving playlists) the UI needs
> 
> list_length
> item_at
> add_item(s)
> remove_item(s)
> move_item
> 
> set_current_position
> get_current_position
> (The current position functionality is special as it is only required for 
> the current playlist, not all playlists.)
> 
> This is just a bare minimum of functionallity that any interface needs to 
> provide to allow the use and manipulation of playlists. Exactly how this 
> functionallity is actually implemented can be flexible, and extra helper 
> functions would quite probably help keep code clean.
> 
> For instance the list_length, add_item, etc... could be implemented by 
> having a function that returns a vector(void 
> get_list_vector(vector<std::string>& list); or something like that). The 
> UI would then edit this vector using the standard vector interface, then 
> set the modified vector as the actual playslist (void 
> set_list_vector(const vector<std::string>& list); for example). This would 
> provide all the required functionality with out explicitly writing 
> functions to do all of it. On the other hand you could implement exactly 
> the functions I've mentioned as the current PlaylistManager class does.

I still prefer the wrapper class that exports a vector interface.
That way I can use it with all the usualy STL functions, but still have
the ability to intercept the calls and do something special. But this 
doesn't really matter. 


> When we got on to playlists with expandable playlist items as has been 
> mentioned, the base functionality of the interface would need to change in 
> only one way. A new function would be required so that the UI could expand 
> an item and get the same result the playlist object would (e.g. void 
> expand_item(std::string item, vector<std::string>& expanded_items);) This 
> should mean that when the UI and the playlist communicate about position 
> of an item, that is a child of an expanded item, they are actually talking 
> about the same child. If the UI expanded items seperatly from the 
> playlist, its possible that they might get different results or results in 
> a different order, which would make the 2 represntations of the 
> playlist(internal playlist object, ui list) out of sync.

I guess the big question here, is whether the list should expand in
place?   I currently don't think so..


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


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.
All the same problems as 



-- 
Kristian G. Kvilekval
email:[email protected] office:(805)893-4276 http://www.cs.ucsb.edu/~kris



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