Re: gui/pager problem on MacOSX

[Ben Abbott]

On Oct 27, 2013, at 7:49 PM, John W. Eaton wrote:

> On 10/24/2013 08:56 AM, Ben Abbott wrote:
>> On Oct 24, 2013, at 7:58 AM, Ben Abbott wrote:
>> 
>>> On 10/11/2013 12:51 PM, John W. Eaton wrote:
>>> 
>>> 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.
>> 
>> Carlo, I had a few minutes to try out the driver.  I built it using a script 
>> containing ...
>> 
>> #! /bin/sh -e
>> CC=/opt/local/bin/gcc-mp-4.7
>> CFLAGS="-pipe -O2 -m64 -D_THREAD_SAFE -pthread"
>> CARBON_LIBS="-Wl,-framework -Wl,Carbon"
>> $CC driver.c -o driver $CFLAGS $CARBON_LIBS
>> 
>> jwe, Using your driver, the pager works for me.  Thanks!
> 
> OK, I checked in a changeset with a more complete program based on
> this idea.
> 
> We now generate three binaries:
> 
>  * octave-cli.  Same as before.
> 
>  * octave-gui.  This is what the "octave" binary was previously, but
>                 now it never forks and so no longer recognizes the
>                 --no-fork option.  If you want to debug the gui, it
>                 is probably easiest to run this under gdb.  However,
>                 because of the way libtool works, octave-gui in the
>                 build tree is a shell script, so a little more work
>                 needs to be done to make this convenient again.
> 
>  * octave.      A new wrapper program that invokes either octave-cli
>                 or octave-gui.
> 
> The "octave" binary now does the following things to decide whether to
> start the GUI:
> 
>  1. Check the command line arguments for --no-gui-libs.  If present,
>     it execs "octave-cli".  This option is not passed on to the
>     "octave-cli" process.
> 
>  2. Check the comand line arguments for --no-gui.  If present, it
>     execs the "octave-gui" binary with the --no-gui option.  In this
>     case, we want to start the binary that was linked with the GUI
>     libraries so that we can do plotting (in the future with Qt
>     widgets) but we start in the command-line mode so we don't give
>     up the controlling tty.  When given --no-gui, the "octave-gui"
>     binary also starts a QApplication context before launching the
>     command-line interpreter.
> 
>  3. If neither of these arguments are present and there is no
>     controlling tty, exec "octave-gui" directly as there is no need
>     to give up the controlling terminal.
> 
>  4. If neither of these arguments are present, then set up signal
>     handling in the parent to pass any signals to the child process
>     then fork and
> 
>       * in the child, give up the controlling terminal and exec
>         "octave-gui" to start the GUI.
> 
>       * in the parent, wait for the child, passing signals to the
>         child.
> 
> Finally, on Windows and Cygwin, where fork was apparently never
> needed, octave always execs "octave-cli" or "octave-gui" instead of
> forking to give up the controlling tty.  Otherwise, the same rules
> apply: --no-gui-libs starts "octave-cli" and --no-gui starts
> "octave-gui" in command-line mode.
> 
> The "octave" main program looks for "octave-gui" and "octave-cli" in
> $bindir as set by configure and Make during the build (after
> substituting OCTAVE_HOME), or by looking at the environment variable
> OCTAVE_BINDIR.  The run-octave script uses OCTAVE_BINDIR to run the
> programs from the src directory in the build tree.
> 
> To exec Octave from a Desktop launcher that starts process without a
> controlling terminal, you could just run the "octave-gui" binary
> directly.  Or, if you want to use the command-line version directly,
> you can invoke "octave-cli".  The wrapper is really only needed if you
> want to run the GUI from a terminal where the process will inherit a
> controlling tty.  But it makes sense to me to have one binary that can
> be given options to do all these things.
> 
> I thought about putting "octave-gui" and "octave-cli" in the $libexec
> directory as a way to try to avoid confusion (I'm thinking that people
> will see the "octave-gui" binary and run it from the command line then
> wonder why the pager doesn't work properly).  But there are cases
> where running "octave-gui" or "octave-cli" directly makes sense, so
> maybe they do belong in $bindir?  I'm not sure what is best here.
> 
> Comments?
> 
> jwe

I just noticed that when building the docs, octave-gui is being run.  I assume 
this isn't intended?

Ben