Another weird backtrace related to cover drawing

[Ian Monroe]

On Wed, Jul 23, 2008 at 5:46 PM, Daniel Winter <dw at danielwinter.de> wrote:
> On Wednesday 23 July 2008 08:33:42 Maximilian Kossick wrote:
>
>> I think it's not a good idea. There's no reason to use querymaker in a
>> synchronous manner in libamarok. Regarding scripting, is there any
>> relevant scripting language that is not able to use callbacks?
>
> There are use cases for doing sync querys.  In a lot of cases were the actual
> work is already done in some worker thread it is extra work to use the async
> event driven QueryMaker without any benefits. Or even worse with extra overhead
> of creating a new thread (not big but anyway) and the event handling.
>
> More complex code to write and more complex code to maintain. In the longterm
> more bugs.
>
> And if that BQ is that useless, why did Nikolaj use it again in in a commit
> from today? (for the CurrentEngine data engine for the context view)

Everyone agrees its very useful, seductively so. Using async methods
takes more work: you have to break up your function into two parts.
But its the cost of writing GUI event-driven code.

I'm going to go ahead and say that Nikolaj's use of it was a bad idea,
though I haven't seen the code in the full context.

> Also Daniel (the biased playlist one ;-)) is using BQ.

I already addressed how it does so for a corner case.

> And for the scripts.  Sure I think all languages supports callbacks.

Given that we only support QtScript which of course does

> But for some easy scripts (and scripts are in a lot of cases easy smaller
> jobs)  I think it would also be very helpful to have a sync way of doing
> querys.  Why using the event  based with extra thread if you does not need it.
> Just to make it harder to use it and create an extra thread (amarok already
> creates  a lot of threads (there are often 14 of them hanging arround))?

So far we haven't given scripts full access to our collection
interface. But when we do, yes I think we should use an async
interface. Its actually less painful to do callbacks in JavaScript
anyways (we could probably do it with inline anonymous functions etc).

> So I am all for having a way of doing sync querys. Just by saying the
> QueryMakers "i want next query blocking" it will then not create a new thread
> and doing the work there.
>
> We could even easly port the BlockingQuery (also I do not see the need for
> that then) port to the "new" Api.

I agree with you here. Its just important to establish that blocking
queries are a bad idea often. :)'

Ian