<div><span style="line-height: 1.5;">If I understand you correctly we should encapsulate the engines behind the </span><span style="line-height: 1.5;">ListEngineService. </span><span style="line-height: 1.5;">I think the SearchListEngine and MetadataListEngine can be combined, most searches would rely on those two engines together rather than one. The FileListEngine can represent a local library (~/Music for eg), cache would be something of a history/recently played list. </span></div><div>I like the ListEngineService and the MediaItem classes, the current itemModel approach is not qml friendly.  This definitely is a much cleaner arch. I'll push the kf5 port, then let's bring your sources (I also think we can drop the legacy folder) we merge and rebase the architecture.</div><div><br></div><div><div style="color:#909090;font-family:Arial Narrow;font-size:12px">------------------</div><div style="font-size:14px;font-family:Verdana;color:#000;"><div><br></div></div></div><div> </div><div><div><br></div><div><br></div><div style="font-size: 12px;font-family: Arial Narrow;padding:2px 0 2px 0;">------------------ Original ------------------</div><div style="font-size: 12px;background:#efefef;padding:8px;"><div><b>From: </b> "Stefan Burnicki";<stefan.burnicki@burnicki.net>;</div><div><b>Date: </b> Dec 12, 2014</div><div><b>To: </b> "bangarang"<bangarang@kde.org>; <wbr></div><div></div><div><b>Subject: </b> Rough architecture / changes to 2.0</div></div><div><br></div>Hey,<br><br>in the last time I played around with thoughts (and little code) about<br>Bangarang's basic architecture. I thought about some things that should<br>be different in the new architecture and created a little graphic giving<br>a rough overview about what I have in mind.<br><br>See the graphic here:<br>http://picpaste.com/pics/bangarang-eDwEMpsw.1418318816.png<br>(I can also include it and it's "source" in the repository, if you want)<br><br>Here some thoughts:<br><br>MediaItem<br>-------------<br>MediaItem should be a QObject with simple properties holding the<br>important data. The data shouldn't be structured by how it's used by the<br>model later on, but how it represents the actual media best. Derived<br>classes can be used for more specific media representation (as<br>MusicMediaItem for music).<br>Each MediaItem as a specific MediaURI that identifies it and where it<br>comes from (i.e. the listengine). It shouldn't be mixed with the URL<br>used to play it. Therefore there's a seperate PlaybackURL property in<br>the MediaItem.<br>A MediaItem can also be of type "category". If it's MediaURI is passed<br>to the right ListEngine, the content of this category will be retrieved.<br><br>ListEngines<br>--------------<br>Previously we had a ListEngineFactory, but I'd like to have a<br>ListEngineService that takes care of even more work itself and can be<br>used as a general interface to the different ListEngines. No other class<br>should need to interact with a ListEngine directly, but just pass a<br>MediaURI to this service and get notified by a signal when the result<br>has arrived.<br>The ListEngineService has a cache it can check for previous results.<br>Otherwise it knows the registered ListEngines, and decide based on the<br>MediaURI which engine to invoke asynchronously.<br><br>I also added functions to get the artwork and playback URLs, in case<br>that the listengines can provide them directly for the whole list. (This<br>is more a feature I want to keep in mind for the future).<br><br>The new MetadataListEngine will internally use QSqlDatabase. At first we<br>should start with SQLite as discussed, but using this class we should be<br>able to easily add support MySQL later on for larger media collections.<br><br>MediaItemModel<br>--------------------<br>The old Bangarang heavily tries to use the item role based approach with<br>the (little confusing) role-structured MediaItem. I would like to try a<br>different approach here: Instead simply provide a "get(int row)"<br>function returning the actual, naturally structured MediaItem. As this<br>is now a QObject with properties, the QML components will be able to<br>work with it and decide how to visualize it. I hope, since its<br>properties implement the NOTIFY option, QML will even be able to<br>dynamically react on changes in that class.<br><br>Playist and MediaBrowser<br>--------------------------------<br>They maintain one MediaItemModel each whose reference is also known to<br>QML. Further more they provide functionality related to their mean<br>(changing the playlist's mode, invoking a search, etc).<br><br>UIInterface<br>--------------<br>This class should have the task to initialize and maintain the<br>connection between the logic components and the UI components. It should<br>connect signals to slots (between C++ and QML) and setting the context<br>for QML, i.e. take care that the QML components have access to the<br>MediaItemModels and the Playlist/MediaBrowser instances.<br><br><br>What do you think of this? Please comment if you have any thoughts and<br>suggestions.<br><br>@Eshton: I just saw you pushed some ported classes and I think they are<br>a good basis to start from and modify them :)<br><br><br>Regards,<br>Stefan<br><br><br><br><br><br><br>_______________________________________________<br>Bangarang mailing list<br>Bangarang@kde.org<br>https://mail.kde.org/mailman/listinfo/bangarang</div><div><br></div><div><div style="color:#909090;font-family:Arial Narrow;font-size:12px">------------------</div><div style="font-size:14px;font-family:Verdana;color:#000;"><div><br></div></div></div>