Hello,<br><br>Based on the discussion we had about what shall be done with core playlist, I got an idea that bypasses the problems.<br><br>Firstly, I think services discovery modules and media library are the only processual components that add playlist items into playlist_t (besides end-user's spontaneous actions). Please correct me if that is not so.<br>
<br>Therefore, my idea is that services discovery mechanism and media library would not form playlist_item_t lists(trees), but every interface would use SD and ML modules directly (since we will soon have the SQL media library module) and interfaces themselves would implement storage of input items obtained through those modules. The plan is therefore to implement obtaining/accessing input items via SD and ML directly in every interface that needs SD and ML.<br>
<br>Thus further changes to playlist functionality could be done much easier. Eventually, playlist_t could store only a simple list of input items, that would represent a flat actual "now playing" playlist, so this would not even need playlist_item_t. Of course, every input item to be played should then be inserted into this exact list, which I believe we agreed upon as the preferred functionality.<br>
<br>If the actual playlist is made flat, it would also make sense that any playlist that user saves for reuse is flat. Thus we would not need tree storage for that either. In the end, playlist_item_t would become obsolete and could be wiped away.<br>
<br>I am ready to try implementing "native" interaction with SD for the qt4 interface (as Qt4 is my field of "specialization"). I would start with implementing another QAbstractItemModel to interact with SD.<br>
<br>Thoughts?<br><br>Cheers,<br>Jakob<br>