Rough architecture / changes to 2.0

[Stefan Burnicki]

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