Re: gui/pager problem on MacOSX

[John W. Eaton]

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