[vlc-devel] playlist: flat / tree separation

Pierre d'Herbemont pdherbemont at gmail.com
Sun Aug 23 11:27:50 CEST 2009

On Aug 22, 2009, at 10:41 PM, Jakob Leben <jakob.leben at gmail.com> wrote:

> Moreover, I think we agree that it is absurd to ever have a  
> flattened "view" of a tree "model" (as in MVC and as in media_list /  
> media_list_view)...

I don't like the tree structure to store my media. I think the tree  
structure is not relevant. Media should be tagged, to be sorted, and  
browsed. That's from a user perspective.

That said, some media might have subitems. Playlist media are such. We  
could decide to always import the content of those playlist items, but  
you may not be able to do that without first doing the expansive task  
of reading the media content first. This means having an import task  
when adding items to your library. That's a technical issue to settle.

End word, media might have sub media. We have a tree here. But that's  
at a deeper level. This would not necessarily be presented to the  
user, or not directly.

For different purpose (ie media discovery) you could imagine different  
way of presenting the data, via a different class of object.

Those object just need to share a protocol so that a common object  
(media player) can know which items to play next.

> ...and that we also agree that we don't need models and views  
> (again: as in MVC) in the core at all (because the core shall only  
> supply models and gui interfaces produce the views).

No, you certainly don't want to incorporate the sorting code in the  
GUI. The UI view just need to be bound to the counter part core view  
object if we want to factorize minimally. Don't get the wrong idea here.

> -----
>  would like to also touch the following topic and check your  
> opinion, even though the answer may be too trivial:
> 1.I think all the media available to the user to play (be it the  
> playlist, the media library, the service discovery listings etc.)  
> shall be finally stored with the same data structure (just like it  
> is now all stored with playlist_item_t structures) - no matter were  
> it comes from. Even SQL media library shall be finally stored with  
> that same data structure (though, as Rémi pointer out, we should nam 
> e that structure differently to not be confused with the actual play 
> list).

As Remi said this should be input_item not playlist item.

> 2.This universal struct shall allow for tree structures (just what  
> now playlist_item_t does), as this means it automatically allows  
> also for list structures.

Yes. This is libvlc_media and media_list. All the core should support  
that easily nowadays.

This must be something at a lower level than the media library, or any  
object that cotresponds to what the user see.

> 3.Now if we call entities like the playlist, the media library, a  
> singular service library's listing with a generic name "media item  
> groups" then the only essential difference between a list and a tree  
> type media item group shall be in a per-media-item-group flag ("this  
> is a list / this is a tree") according to which the generic media  
> group handling functions can determine whether tree structured data  
> must be flattened before inserting it and if it is possible to  
> create nodes in that media group etc.

I don't understand this exactly... This seems too pseudo technical.


More information about the vlc-devel mailing list