Re: g_idle_add patch proposal

[Bastien Nocera <hadess hadess net>]

On Tue, 2013-05-28 at 14:51 +0200, Roland Peffer wrote:
> Well,
>
> till now I only used the diskussed approach for resolving url data
> from vimeo or youtube , as these are not included in the fast keys and
> at least vimeo
> had a blocking call in libquvi.
>
> Regarding the operation cancelation I also tried to run grl_browse in
> a seperate thread with a new GMainContext, and it worked except the
> gdata libe under grl-youtube  made trouble from time to time. Not on
> cancelation , but on next browsing after a cancelation.
>
> Just I have no time right now to get deeper into this.
> Anyway it would be nice to have a solution to let grilo run in a
> seperate thread outside of the default main context.

The correct way to fix this isn't to make grilo callbacks run in a
separate thread, but to make them not block. So the quvi calls shouldn't
be made in grilo synchronously, but asynchronously.

One way you can achieve that is by using totem-pl-parser. You'd do:

if (!totem_pl_parser_can_parse_from_uri(uri, FALSE))
   /* return error */
totem_pl_parser_parse_async (parser, uri, FALSE, ....)

and emit the end of the grilo lookup operation from the callback.

totem-pl-parser is already used by grilo itself, and could be used in
plugins that require quvi support.

See the documentation for more info:
https://developer.gnome.org/totem-pl-parser/stable/TotemPlParser.html

Cheers