[vlc-devel] playlist: flat / tree separation

[Rafaël Carré]

On Fri, 21 Aug 2009 14:43:07 +0200
Jakob Leben <jakob.leben at gmail.com> wrote:

> Hello,
> 
> I remember someone said that the separation between flat and tree
> playlist remained because some modules were not compatible with tree
> playlist. I think keeping this separation complicates many algorithms
> concerning the playlist and I see it as a big step forward to remove
> this separation. Does anybody know of a case where tree structure
> would still be a problem?

I thought the problem was having a way to display tree items like:
cdda://
	cdda://1
	cdda://2
...

directory:///a
	file:///a/1.mp3
	file:///a/2.mp3

While keeping an efficient way to sort flat playlists like:
cdda://1
cdda://2
file:///a/1.mp3
file:///a/2.mp3

> In my opinion we could simply implement a "flatten down" function and
> wherever a flat representation of a tree of items is needed, it could
> be flattened in one step. And I certainly don't see a big profit in
> having a flat and a tree representation at the same time, as
> synchronizing them is quite a problem and even impossible in some
> cases (moving and adding items in flat structure doesn't have a
> uniquely matching and equivalent action in tree structure - regarding
> the item position). I also think that from an end-user's point of
> view, they either want a flat or a tree representation of a group of
> items and they can be offered the "flatten" operation through GUI as
> well.

I think we should identify what use a tree representation and see if
it's really needed there.

> The core of the change would be to have only one "playlist_item_t
> *p_root" field in playlist_t structure and under it only one node for
> playlist, media library and services discoveries each.
> "grep"-ing the vlc repository for "p_root_onelevel",
> "p_root_category", "p_local_onelevel", "p_local_category",
> "p_ml_onelevel" or "p_ml_category" which are fields of public
> playlist_t structure returns only a dozen of different files, so I
> guess the amount of code affected by the change need not be too huge.

except src/playlist/ i believe not much

> If somebody agrees about the benefit in doing this change, I would
> like to hear advice about how to make the transition smooth, meaning
> that the code dependent on the basic change in playlist_t could be
> modified chunk by chunk and not yet adjusted code would still work
> during the process. My idea is to add the new p_root field *besides*
> p_root_onelevel and p_root_category, and modifying the core playlist
> functions to always keep the structures under *p_root* and
> *p_root_category* a copy of each other. Next we implement the flatten
> function. Then we go to modify the relevant code in vlc/modules/ to
> only reference *playlist_t :: p_root* and use the flatten function
> where flat representation is needed. Only in the end we change the
> src/playlist code to forget about p_root_onelevel and p_root_category.

You could well work on this in your local tree (for example creating a
local branch which you would keep in sync with master), and push the
patches once you are finished.

If you need testing you could send your patchset on this ML, or
eventually create a remote branch on the git repo if it helps.

> Any thoughts very welcome, please.

Myself I like using a tree display because I use VLC for my audio
collection, and it is stored as one directory per album.

I know some people are working on a media library storage using sqlite,
so perhaps advanced sorting/display could be moved to this new media
library.

I'd like to hear from the people working on this.

> Best regards,
> Jakob

Good luck with this ;)

-- 
Rafaël Carré
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20090821/2610438f/attachment.sig>