Rough architecture / changes to 2.0

[Andrew Lake]

Stephan,

I think your suggestion makes sense. I became not a fan of the Qt Roles
that Qt seems to recommend in extending the QStandardItemModel since it
conflates data with presentation. So I'm down with the changes you suggest
for all the reasons you suggest. Everything else gets a thumbs up from me.

UIInterface may or may not be necessary since signals and slots can be
directly exposed and connected between the QML and C++ classes. That said,
I can see how it could be useful to provide a consistent place to decide
what should be exposed to the UI layer. So I'm fine if we go with it for
now.

Thanks for putting together the architecture diagram Stephan. If Eshton
agrees with the approach, it'd be nice to check this architecture stuff
into the repo somewhere so that we have it for future reference.

Hope this helps,
Andrew

On Thu Dec 11 2014 at 9:57:54 AM Stefan Burnicki <
stefan.burnicki at burnicki.net> wrote:

> Hey,
>
> in the last time I played around with thoughts (and little code) about
> Bangarang's basic architecture. I thought about some things that should
> be different in the new architecture and created a little graphic giving
> a rough overview about what I have in mind.
>
> See the graphic here:
> http://picpaste.com/pics/bangarang-eDwEMpsw.1418318816.png
> (I can also include it and it's "source" in the repository, if you want)
>
> Here some thoughts:
>
> MediaItem
> -------------
> MediaItem should be a QObject with simple properties holding the
> important data. The data shouldn't be structured by how it's used by the
> model later on, but how it represents the actual media best. Derived
> classes can be used for more specific media representation (as
> MusicMediaItem for music).
> Each MediaItem as a specific MediaURI that identifies it and where it
> comes from (i.e. the listengine). It shouldn't be mixed with the URL
> used to play it. Therefore there's a seperate PlaybackURL property in
> the MediaItem.
> A MediaItem can also be of type "category". If it's MediaURI is passed
> to the right ListEngine, the content of this category will be retrieved.
>
> ListEngines
> --------------
> Previously we had a ListEngineFactory, but I'd like to have a
> ListEngineService that takes care of even more work itself and can be
> used as a general interface to the different ListEngines. No other class
> should need to interact with a ListEngine directly, but just pass a
> MediaURI to this service and get notified by a signal when the result
> has arrived.
> The ListEngineService has a cache it can check for previous results.
> Otherwise it knows the registered ListEngines, and decide based on the
> MediaURI which engine to invoke asynchronously.
>
> I also added functions to get the artwork and playback URLs, in case
> that the listengines can provide them directly for the whole list. (This
> is more a feature I want to keep in mind for the future).
>
> The new MetadataListEngine will internally use QSqlDatabase. At first we
> should start with SQLite as discussed, but using this class we should be
> able to easily add support MySQL later on for larger media collections.
>
> MediaItemModel
> --------------------
> The old Bangarang heavily tries to use the item role based approach with
> the (little confusing) role-structured MediaItem. I would like to try a
> different approach here: Instead simply provide a "get(int row)"
> function returning the actual, naturally structured MediaItem. As this
> is now a QObject with properties, the QML components will be able to
> work with it and decide how to visualize it. I hope, since its
> properties implement the NOTIFY option, QML will even be able to
> dynamically react on changes in that class.
>
> Playist and MediaBrowser
> --------------------------------
> They maintain one MediaItemModel each whose reference is also known to
> QML. Further more they provide functionality related to their mean
> (changing the playlist's mode, invoking a search, etc).
>
> UIInterface
> --------------
> This class should have the task to initialize and maintain the
> connection between the logic components and the UI components. It should
> connect signals to slots (between C++ and QML) and setting the context
> for QML, i.e. take care that the QML components have access to the
> MediaItemModels and the Playlist/MediaBrowser instances.
>
>
> What do you think of this? Please comment if you have any thoughts and
> suggestions.
>
> @Eshton: I just saw you pushed some ported classes and I think they are
> a good basis to start from and modify them :)
>
>
> Regards,
> Stefan
>
>
>
>
>
>
> _______________________________________________
> Bangarang mailing list
> Bangarang at kde.org
> https://mail.kde.org/mailman/listinfo/bangarang
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/bangarang/attachments/20141211/40f47230/attachment-0001.html>