2009/9/29 Jan Hudec <[email protected]>
> You must not call Gtk functions from different thread. Ever.
>
> You have to add an idle handler to the default context that will update the
> progress-bars. So from your thread you do something like:
>
> Idle.add(() => { update-progress-bars(); return false; });
>
OK, so I changed the connect to :
this.download_list.download_progressed += (klass, item_fraction,
total_fraction) => {
GLib.Idle.add( () => {
this.view.item_fraction(item_fraction);
this.view.total_fraction(total_fraction);
return false;
}
);
};
Souns better ? At least, it seems to never stop, unless I resize the
window.
> Another note: GLib, GIO and GTK are designed so that you should not need to
> use threads. The async functions in GIO allow you to do all filesystem and
> network access from the event loop and since vala has support for async
> functions, using the async GIO functions is now easy. Consider using that
> instead of threads, it will make your life easier. Glib may actually
> internally use threads for the operations, but you don't have to care about
> the synchronization that way.
>
I will try async GIO for this particular case.
However, the main point was to experiment Threads and GTK, with Threads
doing long lasting tasks and GTK showing the progress. Here, I have network
downloads, but it could have been long computations, like transcoding audio
or video.
So, I am trying to see how I can cleanly separate each part, and it seemed
to me that emitting signals in the Thread, and connect it in a controller
would be best, as the GUI could be done in various toolkit (GTK, curses,
cli, whatever).
I might be stupid though to do such things :), and it should be done in a
completly different way.
Thanks for your tips
Simon Arnaud
_______________________________________________
Vala-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/vala-list
