Extending a GTK+ Application with Guile

Extending a GTK+ Application with Guile

[Kevin J. Fletcher]

Hello Guilers.

I'm currently writing some prototype code before starting a project and
have a few questions that I hope some of you may be able to answer.

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. 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.

I apologise to those with mail clients not using monospace fonts.

  THREAD1            THREAD2
 ---------           -------
| GTK     |   pty   | guile |
|     VTE |<------->| shell |
|  -----  |          -------
| guile   |
|  scripts|
 ---------

0) Is there anything wrong with this architecture?

   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?

   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)

1) scm_shell allows the `,q' command (and probably some other exit
routes) which kills the whole application. Is there a way to present a
shell (or similar subset) without the ability to exit?

2) Thinking of portability, is guile running on Windows (without
cygwin), to justify the claim of 'ubiquitous'?

Happy Hacking,
Kevin Fletcher.

Re: Extending a GTK+ Application with Guile

[Paul Emsley]

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.

Re: Extending a GTK+ Application with Guile

[Ludovic Courtès]

Hi!

Kevin J. Fletcher <dev@kjfletch.co.uk> skribis:

>   THREAD1            THREAD2
>  ---------           -------
> | GTK     |   pty   | guile |
> |     VTE |<------->| shell |
> |  -----  |          -------
> | guile   |
> |  scripts|
>  ---------
>
> 0) Is there anything wrong with this architecture?

Sounds good at first sight.  In fact, you could look at (system repl
server), which implements something like that.  That’s what the
‘--listen’ command-line option uses.

> 1) scm_shell allows the `,q' command (and probably some other exit
> routes) which kills the whole application. Is there a way to present a
> shell (or similar subset) without the ability to exit?

Actually, ‘,q’ does ‘exit’, which just throws an exception, so it’s
harmless (you can check it with ‘--listen’: typing ,q in the REPL over
telnet doesn’t terminate the process, it just terminates the REPL
server.)

But then of course, if the user calls ‘primitive-exit’ or similar, the
whole process terminates.  You could rebind ‘primitive-exit’ to
something harmless, but I’m not convince that protecting users against
themselves makes sense.

> 2) Thinking of portability, is guile running on Windows (without
> cygwin), to justify the claim of 'ubiquitous'?

It’s supposed to build and run with MinGW, though it’s definitely not
widely tested.

Thanks,
Ludo’.

Re: Extending a GTK+ Application with Guile

[Kevin J. Fletcher]

Paul Emsley <paul.emsley@bioch.ox.ac.uk> writes:

> By "at the same time" do you mean in "a different thread"?
>
> If so, don't do that.

Yes, this was my meaning.

> I use scm_shell() but only for command-line/non-gtk-graphics mode.
> To interact with guile I use guile-gui.
>
> It is not clear to me that you need VTE and threads.

I used VTE as a proof of concept to interect with guile. If better
methods of doing so are possible (as you have suggested) then they will
be addopted.

Thank you,
I will look at coot to better understand the organisation and
interactions with guile.

Kevin.

Re: Extending a GTK+ Application with Guile

[Kevin J. Fletcher]

ludo@gnu.org (Ludovic Courtès) writes:

> Sounds good at first sight.  In fact, you could look at (system repl
> server), which implements something like that.  That’s what the
> ‘--listen’ command-line option uses.

I did see --listen but didn't look to far into it. As my first attempt
(routing STDIN, STDOUT, STDERR through VTE) worked I stopped working on
this aspect. I will add it to my list of options.

> But then of course, if the user calls ‘primitive-exit’ or similar, the
> whole process terminates.  You could rebind ‘primitive-exit’ to
> something harmless, but I’m not convince that protecting users against
> themselves makes sense.

I agree, this appears overkill. I just wondered if it would be seen as
buggy: "I attempted to quit the terminal and the whole program
closed!". It is not a major concern.

Thanks