Re: gui/pager problem on MacOSX

[John W. Eaton]

On 10/11/2013 12:51 PM, John W. Eaton wrote:
> On 10/11/2013 12:16 PM, Michael Goffioul wrote:
>
> > I'm not entirely sure, but wasn't the problem the fact that OS X refused
> > to fork/exec if the base process had already accessed the cocoa
> > framework, which we do (or used to do) through the display_info class?
>
> My idea was to have a simple main program that would give up the
> controlling tty and then exec the real Octave. To preserve the illusion
> of having one program that is running in the terminal, the simple main
> program would wait for the child and pass signals to the child. That way
> you could still control it from the terminal (at least in the sense of
> C-z working to stop the process, for example). Would that work? I'm not
> sure, I haven't tried it.

If the problem is that we can't fork after checking to see whether
there is a graphical display, then I don't know how to solve the
problem of falling back to the command-line interface if the graphical
display is not available.  But judging from the error messages that
Ben posted here:


https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2012-August/029721.html

  "The process has forked and you cannot use this CoreFoundation 
functionality safely. You MUST exec()."

I think we can get away with doing an exec to start the GUI program
after the fork, even if we have already called some GUI functions in
the main program.

So instead of forking without exec, I propose that we create a small
driver program that will

  1. Check to see whether there is a graphical display available.  If
     not, start the command-line version of the program.

  2. Check the command line arguments for --no-gui.  If it is present,
     start the command-line version of the program.

  3. Fork.  In the parent, set up signal handling to pass any signals
     to the child process and wait for the child.  In the child, exec
     the GUI version of the program.

A simple prototype of this idea is attached.

Ben, can you try this and see whether it works?  You'll need to edit
the file to define OCTAVE_INSTALL_DIR to point to the location where
you have a copy of Octave with the GUI installed.  You'll also need to
link with the Carbon libraries.

If this approach works on OS X, then I can work on integrating it with
the Octave sources.  It will still need a more work to also avoid
starting the GUI if a filename has been provided on the command line,
either with a command like "octave foo.m" or "octave < foo.m".  That
logic is already in octave.cc, so it should not be too hard to make
this work.  But it will take some time to get it fully working and
merged with the Octave build system.

jwe

driver.c
Description: Text Data