On Tue, 2001-09-04 at 07:34, v.u.n wrote:
Hi there; I am designing a program that reads lines that a user types in on a console and, in response to those commends, displays various (molecular - not that it matters) structures in a graphical window using GTK+. Of course, the usual line-editing, history, etc, console facilities are highly disirable. To complicate things slightly, some of those commands require the pointer (mouse) input via the aforementioned graphical window. Sometimes, the lines might come not from the console, but from a 'script' file. I am trying to avoid the low-level programming associated with getting and line-formatting and displaying individual key-strokes in the GTK+ event loop. It is almost as if I wanted to start the program from the command-line terminal window and have gets()'s drive the event-loop. Is this possible/practical? Comments, suggestions?
I've attached a program that solves some of your problems. It is
probably not the only solution, but it is simpel and gets you most of
the way.(1)
The architecture is simpel. You have an interpreter that handles all
events, whether textual ui, scripts, or gui, to separate the input from
the behaviour of the app.(2) That's the easy part. Then there's the
interaction with the user. For the GUI case this is just callbacks that
feeds commands to the interpreter. In the attached code there is a
single entry whose activate event sends the contents to the interpreter.
For text-ui you use a GIOChannel to avoid blocking the event loop. (An
alternative is using threads, but in this case that is hardly
necessary). Again it all comes down to a callback that feeds commands to
the interpreter.
HTH
/mailund
FOOTNOTES:
1. The attached code is a muckup and it needs quite a bit of
work before it becomes a useable application. For example:
the input read from stdin should be treated as a stream, not
as producing a complete instruction per callback (this is not
guaranteed as far as I know). To get the nice console
features you mention above, such as history, you could wrap
it in getline or something similar.
2. OK, you might not want *everything* to go through the
interpreter, depending on your app. If you only want the
console to do scripting stuff, while the main part of the
app. is independent of the console, you shouldn't force the
apps event handling through the interpreter. There *is* some
merit in piping both GUI and TUI through the same point, to
get uniform behaviour, but that control need not
necessesarily be interpreting. It could just as well be an
object that both GUI and interpreter calls methods of.
--
A computer lets you make more mistakes faster than any invention in
human history - with the possible exceptions of handguns and tequila.
Mitch Ratcliffe, "Technology Review" (1992)
Attachment:
main.c
Description: Text Data
Attachment:
pgpBJZ4SQAhK2.pgp
Description: PGP signature