Re: [gtk-list] Integrating guile-gtk with other event loops

[Marius Vollmer <mvo zagadka ping de>]

Maciej Stachowiak <mstachow@mit.edu> writes:

> I hope this is an appropriate place for questions about guile-gtk; I
> know of no more appropriate list.

It's ok here, I think.  You could also try guile@cygnus.com, depending
on what kind of problem you have, Gtk or Guile specific.
 
> I am trying to figure out a way to integrate guile-gtk's event loop
> with another event loop, specifically that of scwm.

That's an important topic.  I wanted to do something about this
myself, but I haven't got around to it.  I'm especially interested in
running a event loop in parallel to the normal Guile repl.

> I can now get guile-gtk to load successfully and create windows, but
> the ways I've come up with to integrate the event loops all seem
> hackish; the main problem seems to be that there is a high tradeoff
> between ease of implementation and correctness. Here are the three
> approaches I've thought of:

Do you think that guile-gtk poses special problems compared to a pure
C approach?  I mean, how would you do it from C?  Guile-gtk is
supposed to mirror the C API of Gtk+ fairly closely.  The repl might
be something special, tho.

> * Add the following:
> 
> (lambda () 
>   (while (not (= 0 (gtk-events-pending)))
> 	 (gtk-main-iteration)))

There is 'gtk-update' which does this.

> * Write a mini-library that provides a function which returns the file
> descriptor being used for gdk's X connection. Add an input hook to
> scwm's event loop on this file descriptor which does the same as the
> above solution.

That sounds fine to me.

> * Write a dynamically loaded module that provides a hacked version of
> gtk-main that uses scm_internal_select in place of select; this would
> allow the gtk event loop and the scwm event loop to peacefully coexist
> through Guile's cooperative threads.

I like this one best, provided scm_internal_select is effective, and
Gtk+ does not have problems with threads (although Guile's threads are
cooperative, and don't feel comfortable about using them with a
not-thread safe library, just think of a thread switch occuring during
a callback, and someday we will have POSIX threads).

I'm not sure if I'm doing the Guile guys justice here, but:
scm_internal_select is there, but not all of Guile actually uses it.
That means that we do not have non-blocking I/O yet.  It's on the
schedule for 1.3, tho.

I know there was progress towards thread-safeness in Gtk+.  Is it
there?

> Which is best? I think if the last solution is considered useful, it
> may be worthwhile to provide it in guile-gtk itself so that other apps
> that have their own event loops can use guile-gtk transparently.

Yep.  I would be very happy if you could integrate it.