<div class="gmail_quote">On Sat, Aug 22, 2009 at 5:03 PM, 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=":5w" class="ii gt">You are still answering in a technical way to a "use case" mail.</div></blockquote></div><br>OK, sorry for misunderstanding. I must admit though that I find your terminology misleading. I thought you were speaking about models and views as in MVC. Or in other words, about something like the current media_list/media_list_view pair.<br>
<br>In the end, yes, I agree, we will need to present to the user both lists and trees. But that is very obvious, I would like to speak about implementation.<br><br>About implementation: the purpose of my first mail under this topic was simply to check whether all of you agree that we don't need the same data being stored both as a list and as a tree and trying to synchronize those two. I deduct we all agree on that. Is it so?<br>
<br>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)...<br><br>...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).<br>
<br>-----<br><br> would like to also touch the following topic and check your opinion, even though the answer may be too trivial:<br><br>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 name that structure differently to not be confused with the actual playlist).<br>
The reason for this is encapsulation: So that we can have generic functions operating on all of them, and so that we can have for example one and only QAbstractItemModel implementation that can handle all of them.<br>This may be very trivial, but again, I just wanted to check your opinions.<br>
<br>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.<br><br>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.<br>