Michael R. Head wrote:
> I'll break protocol and reply to my own message _again_...
>
> On Tue, 2007-12-18 at 19:05 -0500, Michael R. Head wrote:
>
>> On Tue, 2007-12-18 at 18:46 -0500, Michael McCann wrote:
>>
>>> Ahh, ok. How else can I accomplish my goal, then? I need to give GTK the
>>> lock, as I'm calling GDK from another function not in the main GTK loop.
>>> I tried leaving out gdk_threads_enter()/leave() in the CPU-intensive
>>> function, but X gives me errors.
>>>
>> Well, I guess what you need to do is to separate out the CPU intensive
>> bits of the function from the widget manipulation bits...
>>
>> my_function() {
>> compute_real_hard();
>>
>> gdk_threads_enter();
>> update_ui();
>> gdk_threads_leave();
>>
>> }
>>
>> Or something like that.
>>
>
> Also, you can skip using gdk_threads_enter() and gdk_threads_leave() if
> you instead use g_idle_add(update_ui) and make update_ui a suitable
> callback:
>
> http://library.gnome.org/devel/glib/stable/glib-The-Main-Event-Loop.html#g-idle-add
>
> mike
>
>
Ok, I tried the g_idle_add() idea out:
NonUIThread Calls foo() ->
foo() calls g_idle_add(), which is passed a GSourceFunc, bar(),
along with some data it needs ->
bar() runs a bunch of GDK calls (gdk_threads_enter()/leave() is
_not_ called, neither in foo() nor bar())
foo(), after calling g_idle_add(), immediately begins executing
statements after the g_idle_add() call. However, bar() still holds up
the UI...
Ack!
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
