Re: [slang-users] Fwd: SLgtk 0.5.9 and Vwhere 1.2.2 released

[Michael Noble <mnoble@xxxxxxxxxxxxx>]

Hello Paul,

> Is it supposed to work with gtk 2.0?

Most of SLgtk is automatically generated, so (as you observed) the C code
for gtk-module.so should build sans complaint on just about any self-
consistent set of Gtk 2.x headers.

> ,----
> | Note that SLgtk should build with "stock" Gtk 2.0 distributions that are 
> `----

I will update that verbiage to say "Gtk 2.x distributions," so as to avoid
the potential for misinterpretation.  FYI, the PLATFORMS file in the root
of the distribution enumerates most of the Gtk versions against which SLgtk
is known to have built.

> I commented this out (I have gtk 2.0.2), it built OK.  The demos don't work
> out of the box, there are some missing functions.

This is one of the reasons the configure script looks for version 2.2 or
greater.  More importantly, some of the guilets we use here rely upon
pixbuf routines present only in 2.2 or later.

Incidentally, a new set of binary distributions was also posted last week.

> I've been trying to use this module with the prerelease of JED
> 0.99-17.  See <http://jedmodes.sf.net/mode/jedgtk>.

Wonderful!  I'm delighted to have the feedback.

> It seems there is no way to interact with JED's window while it's 
> displaying a GTK window

Yes, SLgtk guilets currently operate under the assumption that the launching
application passes the primary thread of control to them.

Perhaps the single greatest reason for this approach is that, as you are
probably aware, S-Lang itself is not thread-safe; it would be dangerous to
permit multiple Gtk signal (or idle, timeout, etc) handlers to concurrently
callback the interpreter.

I am aware, though, that if GLib (a lower-level Gtk dependency) is built
with thread support then Gtk can at least be made thread-aware.  So in
principle we might relax the single-thread-of-control restriction slightly
by employing some mutex-based locking.  Given the way we (here@MIT, that
is) have typically used guilets, however, pursuing this further hasn't
been a priority.

> that is, I can press buttons in the GTK window that call functions that
> act on JED's window, but I can't continue editing in JED with a GTK window
> in the background?  Also in xjed the screen redrawing seems to be affected
> somehow, see the jedgtk_search script.

Ok, I'll take a look at your scripts after I dig out from an atypical week
of meetings.  In the meantime, thanks again for your efforts and commentary.

Regards,
Mike

_______________________________________________
To unsubscribe, visit http://jedsoft.org/slang/mailinglists.html