Rough architecture / changes to 2.0

Tue Dec 16 14:47:06 UTC 2014

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/20141216/ebcff860/attachment.html>