Re: gui/pager problem on MacOSX

[Ben Abbott]

On Oct 24, 2013, at 3:32 AM, John W. Eaton wrote:

> 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>

Carlo,

You mentioned you've installed a developer's version of Octave (I have not).  
Can you test jwe's driver?

Ben