[vlc-devel] playlist: flat / tree separation

[Jakob Leben]

On Sat, Aug 22, 2009 at 1:47 AM, Jean-Baptiste Kempf <jb at videolan.org>wrote:

> So, do we need flat views? yes
> Do we need trees views? very likely, in some situations, like Services
> Do we need trees for current playlist? possibly not, but if you
> implement it for Services, how is it different now?
>
> Could they be the same internally (trees) and flat would just be the
> view, when required?
>

I am sorry, maybe I am missing a point, but I still don't understand why we
need flat views of tree data? When you need to display a flat presentation
of a portion of data that is otherwise stored in a tree structure, then you
take copies of data from the tree structure and put those copies together
into a list and then present the list. What you did is you didn't only
display data in a list form, but you created new data which is now in a list
structure and then you displayed it, naturally as a list. And all structural
operations exhibited on that list shall be exhibited on that exact list
structure and only on it, not on the original data which you copied from the
tree structure.

On Sat, Aug 22, 2009 at 1:47 AM, Jean-Baptiste Kempf <jb at videolan.org>wrote:

>  - Playlists are playlists, and people want to sort and rearrange
>   them... Which is difficult to do in a tree-view.
>   1) We need flat views


Why do we need flat views again? Why is sorting and rearranging difficult in
a tree view? We have it working and it's nice.
I still think the playlist could be possibly forced flat, but the reason
would not be difficulty of sorting and rearranging, but only one solely
tradition and common sense as to what a playlist is supposed to mean (media
items that follow each other in time - no notion of parent-child
relationships).

On Sat, Aug 22, 2009 at 1:47 AM, Jean-Baptiste Kempf <jb at videolan.org>wrote:

> The views are going to be the Qt4 and Mac OS X interfaces (yeah, I don't
> care about other interfaces), but those views are not able sort nor to
> move correctly items in the current playlist.


It is not the views that are not doing sort and move correctly, it is the
default models - the ones that are used for example in the Qt4's already
compound model-view QTreeWidget (and not QTreeView, which is only the view
part). That is why we have our implementation of QAbstractItemModel, and it
works just fine with a QTreeView.
 Anyway, I don't see why this problem of default models is relevant to the
topic. We did our own QAbstractItemModel implementation and we are happy
now.

On Sat, Aug 22, 2009 at 1:47 AM, Jean-Baptiste Kempf <jb at videolan.org>wrote:

> Sorting is done by the core (core must know what to play next),
> and moving items can be tricky, (because of trees rendered in flat).


And once again. Why should be have those trees rendered in flat? Scenario:
you wanna search for data which is stored in a tree structure, you prefer to
have the search results in a list instead, and you get it in a list, but
what you should get is a COPY of the (relevant, searched-for) data from the
tree strcuture and operations shall be exhibit only on that copy. Equally:
why would you ever want to present tree structured data in a list, and then
carry out on the tree structure the operations which are requested on the
structurally different displayed data? Why, if we can avoid it? If a user
wants to have a flat playlist, then in his instance of VLC the data is also
STORED in a list, why should it be stored as a tree instead? For whom
(what)?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20090822/145b3565/attachment.html>