On 24/05/12 20:11, Kevin J.Fletcher wrote:
Hello Guilers.
My intent is to add guile as a method of [optionally, at build time]
extending a GTK+ application. With the addition of being able to run
guile scripts I hope to provide a guile-shell to give real-time
interactive power.
Very good. That is what I do with Coot.
First a question of program architecture;
As the guile extensions are optional I run GTK on a main thread and the
shell on a second pthread. I connect the shell through a PTY to the
virtual terminal widget.
THREAD1 THREAD2
--------- -------
| GTK | pty | guile |
| VTE |<------->| shell |
| ----- | -------
| guile |
| scripts|
---------
Bleugh!
0) Is there anything wrong with this architecture?
Yes.
a) Is it valid to use both scm_shell and other guile code at the same
time or is scm_shell designed to run in isolation?
By "at the same time" do you mean in "a different thread"?
If so, don't do that.
I use scm_shell() but only for command-line/non-gtk-graphics mode.
To interact with guile I use guile-gui.
b) Not related to guile but while I'm here I may as well ask. Is there
a more appropriate GTK+ method of communicating (STDIN, STDOUT,
STERR) with the running application (to replace the VTE above)
It is not clear to me that you need VTE and threads.
I have my guile-scripts/functions (well, 99% of them) run in the
main/gtk thread - many using timeout functions.
2) Thinking of portability, is guile running on Windows (without
cygwin), to justify the claim of 'ubiquitous'?
My understanding is that it is possible, but non-trivial. We have not
made a guile-enabled Coot on Windows (yet).
HTH,
Paul.
