Rough architecture / changes to 2.0
Eshton Robateau
2607922181 at qq.com
Mon Dec 22 01:21:55 UTC 2014
I'll work on modifying MediaItemModel and friends to use
the new MediaItem class.
------------------
------------------ Original ------------------
From: "Stefan Burnicki";<stefan.burnicki at burnicki.net>;
Date: Dec 16, 2014
To: "Eshton Robateau"<2607922181 at qq.com>; "bangarang"<bangarang at kde.org>;
Subject: Re: Rough architecture / changes to 2.0
Alright, I think the next logical steps will be to (re-)implement ListEngineService and modify MediaItemModel to correspond to the new architecture.
I pushed MediaUri and MediaItem as the basic data classes to be used to the review board. When we need it, we can derive PlayableMediaItem and MusicMediaItem with additional fields.
With which class do you intend to start? I just want to prevent that we both work on the same class.
Oh, and another topic: How do we handle copyrights in the header? Just enter the person who created the file originally and add contributors, or use some generic "Bangarang Contributors"?
Am 13.12.2014 um 16:13 schrieb Eshton Robateau:
Ok that's sensible. We have a meta list engine (SearchListEngine) and
a ListEngineService through which we can abstract away enough
of the plumbing logically. I think having the search inside MediaUri
is less intrusive and messy than implementing inside the engines.
I'm going to be following your lead on this so let me know what I should tackle next.
------------------
Eshton
------------------ Original ------------------
From: "Stefan Burnicki";<stefan.burnicki at burnicki.net>;
Date: Dec 12, 2014
To: "Eshton Robateau"<2607922181 at qq.com>;
Subject: Re: Rough architecture / changes to 2.0
Hey,
On 11.12.2014 at 19:57 Eshton Robateau wrote:
If I understand you correctly we should encapsulate the engines behind the ListEngineService.
Yes, to avoid unnecessary contact with ListEngines, staying flexible with ListEngines, and having a clear API.
I think the SearchListEngine and MetadataListEngine can be combined, most searches would rely on those two engines together rather than one.
The idea is to search through multiple sources/ListEngines. That means each ListEngine would need to implement a search functionality, maybe simply by a standard MediaURI (enginname://search?term={searchterm}). The SearchListEngine can than be a kind of meta ListEngine which uses other engines. This allows the user to find stuff on the local fie system, saved playlists, etc.
The FileListEngine can represent a local library (~/Music for eg),
Yes, and files in general. Either by asking Baloo for sound files, or by browsing through the filesystem (as we have it in the old version)
cache would be something of a history/recently played list.
Yes. Like when we loaded a saved list (i.e. m3u file), this list can be used again until the file changed. Or maybe we can cache results from queries to the MetaListEngine or search results, for at least some seconds if they don't include stuff like "recently played" which will change often. Maybe the MediaLists returned by the ListEngine should offer a flag if it can be cached/how long it can be cached/offer a cache validation callback.
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.
The code I'm currently having is more some trying-around-stuff than things to actually push right away. But I will start to push new MediaItem classes in the next days and then work from left to right on the graphic.
Regards,
Stefan
------------------ Original ------------------
From: "Stefan Burnicki";<stefan.burnicki at burnicki.net>;
Date: Dec 12, 2014
To: "bangarang"<bangarang at kde.org>;
Subject: Rough architecture / changes to 2.0
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
------------------
_______________________________________________ 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/20141222/2a0eb489/attachment-0001.html>
More information about the Bangarang
mailing list