Another weird backtrace related to cover drawing

[Ian Monroe]

On Wed, Jul 23, 2008 at 1:33 AM, Maximilian Kossick
<maximilian.kossick at googlemail.com> wrote:
> 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.

Then how do you explain SqlMeta's use of BlockingQuery? Wasn't your
suggestion of having SqlMeta execute the SQL itself essentially the
same as a hypothetical-synchronous call to QueryBuider?

> 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.

You are correct, scripts don't need them. And dynamic playlists only
need to use them in the unique event that there isn't a next track
when the track has finished (eg when you first start off using dynamic
playlists), but even this could probably be worked around.

The main point is that Daniel's suggestion would allow a
implementation for BlockingQuery that didn't crash Amarok fairly
regularly in hard-to-figure-out ways. And it makes lots of sense for
already-threaded operations.

Ian