Another weird backtrace related to cover drawing

[Maximilian Kossick]

On Tue, Jul 22, 2008 at 8:10 PM, Ian Monroe <ian at monroe.nu> wrote:
> On Tue, Jul 22, 2008 at 12:06 PM, Daniel Winter <dw at danielwinter.de> wrote:>
> [snip]
>> If the BQ could not be fixed (do not know enough about the workings of the Qt
>> event system),  I would propose a workaround by changing the QueryMaker Api.
>>
>> a new method
>> void QueryMaker::blocking( bool )  (witout calling it, it is non blocking,
>> with true the QueryMaker itself will block).
>>
>> and
>> DataList QueryMaker::results( void )  to get the result in that case.
>>
>> Sure that would mean to change all QueryMakers, but in terms of code reuse and
>> also just to have that feature it would be a better solution in the longterm.
>> (if bq can not get fixed)
>
> After talking to Daniel in the channel, I think is a good idea.
>
> I do think that using QueryMaker in a synchronous manner from the GUI
> thread should be discouraged.  Using QueryMaker's asynchronous methods
> is more difficult, but its how your supposed to do heavy tasks in GUI
> programs. BlockingQueries use of processEvents tried to get the best
> of both worlds (doing work in a thread, but the design simplicity of a
> sync function call) and failed. But there was a good reason to have
> these queries done in a thread to begin with that we shouldn't forget.
>
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?
regarding spreading sql/sparql queries all over the place...all
classes in a collection/service plugin are tightly coupled to each
other. There's no reason that repcaling BlockingQuery in those plugins
would result in query language statements all over the place...the
easiest way i can think of off the top of my head is to provide a
method accessible only within the plugin that allows access to the
completed query.

Max