I agree with Bart, it looks pretty good. One thing to be careful of though:
you are quite often calling playableUrl() to determine whether the url is
accessible. If I remember correctly there is one case, MtpCollection, that
has to copy the file to a temporary location before or within playableUrl(
Additionally, you can dump the complete database content into csv files, one
per table, including column headers. There's a way to start the dump from
the script console, but I forgot which command it is exactly. They'll be in
your home directory. For even more fun, you can magically configure Amar
Good idea. Although I'd recommend to drop the additional collection
implementation or make it an optional goal.
In my opinion properly untangling the dependency mess that is Amarok,
not only with respect to Backend<->GUI but also Backend<->Backend, is
going to be hard enough.
There should be netwo
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100723/#review1649
---
I'm not sure about the need to abort the QMs. The QM -> model co
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100182/#review451
---
- Maximilian
On 2010-12-01 17:06:40, Ralf Engels wrote:
>
> --
.@gmail.com, amarok-devel@kde.org
>> Cc: kde-comm...@kde.org
>> Message-ID: <4cd55226.9030...@kde.org>
>> Content-Type: text/plain; charset="utf-8"
>>
>> On 11/06/2010 05:38 AM, Maximilian Kossick wrote:
>> > One of the reasons for collection s
One of the reasons for collection scanner as a separate executable was
to prevent a crash in collectionscanner from bringing down Amarok as
well. As both processes only communicated with each other via files or
stdout/stdin, this was relatively safe. Is it ensured that a
corrpution of the shared me
