Re: guile-gtk-0.8 and ref counting stuff

[Marius Vollmer <mvo zagadka ping de>]

Scott Dybiec <sdybiec@humanfactor.com> writes:

> Great work!  I have been following guile-gtk and have two questions.

Thanks!

> 1.  I just downloaded the 0.8 version, applied the interp patch to a vanilla
> 0.99.0 GTK and compiled.  calc.scm and hello.scm ran fine, but test-gtk.scm
> fails.  Are you having the same problem?

test-gtk.scm works fine for me.  Note that you have to run it
differently than hello.scm.  This should do it

    % ./guile-gtk -e main -s test-gtk.scm

You can also get a repl

    % ./guile-gtk -l test-gtk.scm
    gtk>

Or you can load it interactively

    % ./guile-gtk
    gtk> (load "test-gtk.scm")
    gtk>

> 2.  I am working on a multithreaded GUI using GTK and am
> implementing it using what I am calling a thread proxy.

Yes, that would be great to have.

> All GTK calls will be made by a single thread dedicated to
> maintaining the GUI, and other threads can send it messages telling
> it what commands to execute.  It seems that there is some overlap
> between the work you have done using gtk.defs to enable guile calls
> and this idea. I need the proxy thread to interpret the messages
> sent to it.  Any thoughts?

gtk.defs is meant to describe the exported features (objects,
functions, constants) of Gtk in greater detail than their C rendition.
If you want to mirror these features one-to-one in your message
protocol, you should be able to make good use of gtk.defs.

The whole concept of a server thread and its clients sounds a lot like
the CORBA stuff to me.  Maybe you want to investigate automatically
converting gtk.defs into the CORBA Interface Definition Language.
Maybe that would be overkill.

> Are the additions you are making to GTK (gtk_input_add_interp)
> at all helpful for this?

Guile-gtk understands only a handful of calling conventions (see the
PROPOSAL in the disty).  Not all Gtk functions follow these
conventions, so there have have to be special _interp versions of
these functions.

The selected conventions could be just the right ones to allow
marshalling the arguments for the wire (your message structures).  I
don't know.  If you need to make additional restrictions/conventions I
would be glad to incorporate them into Guile-gtk and Gtk itself.  Not
so much for the thread-safetry reason but for making Gtk fit for
remote procedure calls.

> Is the GUBI stuff coming also with a common solution to this issue?

I think Tim Janik is working on a significantly improved gtk.defs
specification, but I don't think he is specifically addressing
thread-safety issues.  Well, Tim, speak for youself.

cheers,
 Marius