> I am currently redesigning a program that shall accept input
> from both a GUI and from a terminal window that runs irb.
>
> In reaction to the input, some output will be written to the
> terminal or/and some controls in the GUI will change.
>
> I need help on the basic architecture of such a system.
> I have two rather vague ideas:
>
> (1) Somehow run the irb terminal within the GUI's event loop?

Some toolkits provide for actions-when-idle ("idle" is the keyword for at
least one of them) or perform-this-action-after-that-delay.

*nix only (I don't know how M$ and Mac/cocoa behave in this regard):

The main PITA with GUI threads is that they think that they are the main
program. From that "design", it follows that those threads tend to block
natively when waiting for input, thus blocking all other Ruby threads. It
results in crazy constructions to embed one in the other, even without Ruby
in between, including an X11 extension that shouldn't have been (passing
focus from one toolkit to another).

irb uses readline; readline has a similar problem.

> (2) One thread runs the GUI, one thread runs the terminal?

(3) One program irb, one GUI, both talk with drb to the real program (which,
coincidentally, has a nice mutex somewhere to protect it from race conditions).

(4) Use a multi-line text widget to emulate irb