<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Alright, I think the next logical steps
will be to (re-)implement ListEngineService and modify
MediaItemModel to correspond to the new architecture.<br>
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.<br>
<br>
With which class do you intend to start? I just want to prevent
that we both work on the same class.<br>
<br>
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"?<br>
<br>
Am 13.12.2014 um 16:13 schrieb Eshton Robateau:<br>
</div>
<blockquote cite="mid:tencent_1538F70D60A736A0343C9C7F@qq.com"
type="cite">
<div>Ok that's sensible. We have a meta list engine
(SearchListEngine) and</div>
<div>a ListEngineService through which we can abstract away
enough </div>
<div>of the plumbing logically. <span style="line-height: 1.5;">I
think having the search inside MediaUri </span></div>
<div><span style="line-height: 1.5;">is less intrusive and messy
than implementing inside the engines.</span></div>
<div><span style="line-height: 1.5;"><br>
</span></div>
<div>I'm going to be following your lead on this so let me know
what I should tackle next.</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>Eshton</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";<a class="moz-txt-link-rfc2396E" href="mailto:stefan.burnicki@burnicki.net"><stefan.burnicki@burnicki.net></a>;</div>
<div><b>Date: </b> Dec 12, 2014</div>
<div><b>To: </b> "Eshton Robateau"<a class="moz-txt-link-rfc2396E" href="mailto:2607922181@qq.com"><2607922181@qq.com></a>;
<wbr></div>
<div><b>Subject: </b> Re: Rough architecture / changes to 2.0</div>
</div>
<div><br>
</div>
<div class="moz-cite-prefix">Hey,<br>
<br>
On 11.12.2014 at 19:57 Eshton Robateau wrote:<br>
</div>
<blockquote cite="mid:tencent_2AFB3E0F3E9584234D48760C@qq.com"
type="cite">
<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></div>
</blockquote>
Yes, to avoid unnecessary contact with ListEngines, staying
flexible with ListEngines, and having a clear API.<br>
<blockquote cite="mid:tencent_2AFB3E0F3E9584234D48760C@qq.com"
type="cite">
<div><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.</span></div>
</blockquote>
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.<br>
<blockquote cite="mid:tencent_2AFB3E0F3E9584234D48760C@qq.com"
type="cite">
<div><span style="line-height: 1.5;">The FileListEngine can
represent a local library (~/Music for eg),<br>
</span></div>
</blockquote>
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)<br>
<blockquote cite="mid:tencent_2AFB3E0F3E9584234D48760C@qq.com"
type="cite">
<div><span style="line-height: 1.5;"> cache would be something
of a history/recently played list. </span></div>
</blockquote>
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.<br>
<blockquote cite="mid:tencent_2AFB3E0F3E9584234D48760C@qq.com"
type="cite">
<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>
</blockquote>
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.<br>
<br>
Regards,<br>
Stefan<br>
<br>
<br>
<br>
<blockquote cite="mid:tencent_2AFB3E0F3E9584234D48760C@qq.com"
type="cite">
<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";<a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:stefan.burnicki@burnicki.net"><stefan.burnicki@burnicki.net></a>;</div>
<div><b>Date: </b> Dec 12, 2014</div>
<div><b>To: </b> "bangarang"<a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:bangarang@kde.org"><bangarang@kde.org></a>;
<wbr></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>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://picpaste.com/pics/bangarang-eDwEMpsw.1418318816.png">http://picpaste.com/pics/bangarang-eDwEMpsw.1418318816.png</a><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>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:Bangarang@kde.org">Bangarang@kde.org</a><br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://mail.kde.org/mailman/listinfo/bangarang">https://mail.kde.org/mailman/listinfo/bangarang</a></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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Bangarang mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Bangarang@kde.org">Bangarang@kde.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://mail.kde.org/mailman/listinfo/bangarang">https://mail.kde.org/mailman/listinfo/bangarang</a>
</pre>
</blockquote>
<br>
</div>
</blockquote>
<br>
</body>
</html>