Simulating an Interactive Shell
Many elements in gtkdialog accept an input file sub-element.
If we provide a text, entry, or edit element with an input file,
it will autopopulate the element’s text with the file’s contents.
However, this happens when the element is initially created,
so we must use a refresh action
to update the text after our command has run.
In order to do this, we must store our text in variable elements.
Specifically, we’ll associate a variable with a particular element
by putting the variable tag inside the opening and closing tags of the element.
If we do this for an element that displays text
and gets its input from a file,
and then execute a refresh action on the variable,
the text-displaying element will refresh its content
from the current version of the file.
Similarly, if we use an element that accepts text input from the user
and embed a variable tag within it,
the element will store the content of the text input
in the variable.
We can then reference these variables using
Bash-style variable substitution in our button actions.
Combining all of this,
we can write a functional pseudo-terminal interface.
We’ll need a command input box
that will store the command the user enters in a variable.
We’ll also need an edit element that will display the output of the commands,
which by design will also allow copy and paste operations.
This element will be populated by an input file,
which will contain the results of the command output.
We’ll then use a button element,
that will take the shell command variable from the entry box,
run it via an action,
and write the results to the command output file.
A second action embedded in the button
will then refresh the edit element’s embedded variable object.
This will trigger the display content in the edit box to refresh,
giving the illusion of a dynamic terminal window.
We’ll save our terminal window markup as terminal.txt,
and then run it as we did the previous gtkdialog example.
When we enter commands into our text element,
and click Run!,
the output of the command is displayed as if we had entered it
from a standard terminal window.
This is a very effective solution given the limitations of this kiosk,
and demonstrates the potential effectiveness
of “living off the land” with native tools.