<div class="gmail_quote">On ti 11. elokuuta 2009 19.54.07, Jakob Leben wrote:<br>
> Essentially, what you do when subclassing QAbstractItemModel is not creating<br>
> a(nother) model, but just implementing functions through which the view gets<br>
> data from wherever you have it stored.<br><br>On Wed, Aug 12, 2009 at 9:50 AM, Ilkka Ollakka <span dir="ltr"><<a href="mailto:ilkka.ollakka%2Bvlc@oamk.fi">ilkka.ollakka+vlc@oamk.fi</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=":10o" class="ii gt">Actually playlist_model is allready subclassed from QAbstractItemModel,<br>
but data-handling is maybe littlebit suboptimal</div></blockquote></div><br>Yes, and it's a pity that it had to implement it's own model (class PLItem). I presume that was (is) needed just because it had to store playlist item ID's instead of playlist item pointers. So there we have this kind of duplication of data: some data is stored twice, once in playlist_item_t and again in PLItem, just so that the latter doesn't need to PL_LOCK and search for data everytime it needs it.<br>
If it was not for that ID abstraction from playlist_item then PLModel could do away with PLItem, I believe.<br><br>Another thing is of course the lack of handy and optimal helper functions in vlc_playlist.h, which is the reason for some unnecessary searching for data (array transversals) and similar.<br>