[vlc-devel] commit: various modules: adjust to new playlist design (Jakob Leben )

[Jakob Leben]

On Tue, Feb 2, 2010 at 8:50 AM, Pierre d'Herbemont <pdherbemont at free.fr>wrote:

>
> Well, input_item_AddSubItem2 is non obvious. Very suspicious.
>

> +    input_item_node_t *p_subitems = input_item_node_Create(
> p_current_input );
>
> Why do you need this? Couldn't you emulate this with
> input_item_AddSubItem()?
>
> It seems that this new API is much more complicated than it was
> before, and there is no reason why. Mostly everything could be done on
> top of the previous API.
>

 Well, to be honest, I took the option of a flat playlist as a must. Based
on this assumption, after thinning the playlist to not store separate tree /
flat hierarchy, we need to know when an input item _stops_ adding subitems
to implement the flattening properly.

The most efficient design was to let playlist demuxers actually transmit
over the whole tree of subitems that they create at the same time.
input_item_node was a logical step. And _Create, _Append, _Delete are there
for manipulation of the input item tree, before it is actually sent over
with input_item_AddSubItemTree.

To be handy, I also implemented input_item_AddSubItem2 for demuxers that
create only one single subitem - there is couple of them; but as a
difference from input_item_AddSubItem, the version 2 emits the same event as
input_item_AddSubItemTree.

I kept the input_item_AddSubItem everywhere, so everything works also where
the old event is being observed, for example in vlc_media_xxx - that is,
until those places are converted to observe the react to the new input item
event. Then we can remove the number 2 next to function name...

Cheers,

Jakob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20100202/ad264a14/attachment.html>