Re: [Vala] Problem with Thread, GTK and signals

[Simon Arnaud <mazwak gmail com>]

2009/9/29 Jan Hudec <bulb ucw cz>

> 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