[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Extending a GTK+ Application with Guile
From: |
Kevin J . Fletcher |
Subject: |
Extending a GTK+ Application with Guile |
Date: |
Thu, 24 May 2012 20:11:50 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) |
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.
- Extending a GTK+ Application with Guile,
Kevin J . Fletcher <=