<div class="gmail_quote">On Sat, Aug 22, 2009 at 1:47 AM, Jean-Baptiste Kempf <span dir="ltr"><<a href="mailto:jb@videolan.org">jb@videolan.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div id=":xo" class="ii gt">So, do we need flat views? yes<br>
Do we need trees views? very likely, in some situations, like Services<br>
Do we need trees for current playlist? possibly not, but if you<br>
implement it for Services, how is it different now?<br>

<br>
Could they be the same internally (trees) and flat would just be the<br>
view, when required?</div></blockquote></div><br>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.<br>
<br>On Sat, Aug 22, 2009 at 1:47 AM, Jean-Baptiste Kempf <span dir="ltr"><<a href="mailto:jb@videolan.org">jb@videolan.org</a>></span> wrote:<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
 - Playlists are playlists, and people want to sort and rearrange<br>
   them... Which is difficult to do in a tree-view.<br>
   1) We need flat views</blockquote><div> </div><div>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.<br>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).<br>
<br>On Sat, Aug 22, 2009 at 1:47 AM, Jean-Baptiste Kempf <span dir="ltr"><<a href="mailto:jb@videolan.org">jb@videolan.org</a>></span> wrote:<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
The views are going to be the Qt4 and Mac OS X interfaces (yeah, I don't<br>
care about other interfaces), but those views are not able sort nor to<br>
move correctly items in the current playlist.</blockquote><div> </div><div>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.<br>
 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.<br><br>On Sat, Aug 22, 2009 at 1:47 AM, Jean-Baptiste Kempf <span dir="ltr"><<a href="mailto:jb@videolan.org">jb@videolan.org</a>></span> wrote:<br>
<blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">Sorting is done by the core (core must know what to play next),<br>
and moving items can be tricky, (because of trees rendered in flat).</blockquote><div><br>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)?<br>
</div></div></div>