> Yes, I've read if from one of your previous mails, but that's not really a
> "solution". It involves running the graphics system in a separate process
> and communicate with the base program through pipes. That's typically what
> we tried to avoid by using a in-process separate thread.
That's why I hesitated to call it a "fix".
Nevertheless, that's what it took for both the wxt and qt terminals
to get them running on OSX.
> Note that using
> that approach in gnuplot actually doubles the data transfer when using it
> from octave: first to transfer data from octave to gnuplot, then to
> transfer data from gnuplot to the separate process running the Qt terminal.
>
> Michael.
Not necessarily. I'm not up to speed on what your plans are, but if the
idea is to bypass gnuplot you could still in principle decide to use
gnuplot_qt as the graphics engine and drive it directly from octave without
going through gnuplot proper. That is, you could piggyback on the
gnuplot|gnuplot_qt API. Still a separate process, but only one rather
than two.
Our problem is a bit different. The GUI *is* the main process/thread, but the forking came because we want to integrate a terminal widget within the interface. This means we need to dissociate our process from its current terminal and attach it with the PTY running within our embedded terminal widget, such that the PTY becomes the real stdin/stdout/stderr and /dev/tty of the current process. This apparently was a not-so-trivial issue under Linux and the only solution so far has been to fork and use setsid() (for instance, this is not needed under Win32 where you can easily detach and re-attach to a different console without spawning a child process). But the fork trick is apparently a problem under Mac OS X. If there was a clean way to dissociate from current terminal and re-attach to another PTY without forking, I'd be more than happy to use it, but I haven't find such solution so far.
Gnuplot's problem is the opposite: running a GUI in a separate/child thread, while the CLI is running in the main thread. This is not possible under Mac OS X. The only solution is to run the CLI as a separate thread and keeps the GUI in the main thread, which is what we do, but we end up to a another related Mac OS X limitation.
In any case, if you come up with some alternative that allows running
a only single process on OSX I'd very much like to hear about it.
I was never able to find an OSX guru who could produce such a creature.
In our case, I think what may work (not tested) is to re-exec octave after the fork with some special argument to avoid re-fork'ing.
Michael.