[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gui/pager problem on MacOSX
From: |
John W. Eaton |
Subject: |
Re: gui/pager problem on MacOSX |
Date: |
Sun, 27 Oct 2013 19:49:02 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 |
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
- Re: gui/pager problem on MacOSX, (continued)
- Re: gui/pager problem on MacOSX, Ben Abbott, 2013/10/11
- Re: gui/pager problem on MacOSX, John Swensen, 2013/10/11
- Re: gui/pager problem on MacOSX, John Swensen, 2013/10/11
- Re: gui/pager problem on MacOSX, Ben Abbott, 2013/10/11
- Re: gui/pager problem on MacOSX, John W. Eaton, 2013/10/11
- Re: gui/pager problem on MacOSX, Michael Goffioul, 2013/10/11
- Re: gui/pager problem on MacOSX, John W. Eaton, 2013/10/11
- Re: gui/pager problem on MacOSX, John W. Eaton, 2013/10/24
- Re: gui/pager problem on MacOSX, Ben Abbott, 2013/10/24
- Re: gui/pager problem on MacOSX, Ben Abbott, 2013/10/24
- Re: gui/pager problem on MacOSX,
John W. Eaton <=
- Re: gui/pager problem on MacOSX, Ben Abbott, 2013/10/27
- Re: gui/pager problem on MacOSX, Ben Abbott, 2013/10/28
- Re: gui/pager problem on MacOSX, Michael Goffioul, 2013/10/11
- Re: gui/pager problem on MacOSX, John W. Eaton, 2013/10/11
- Re: gui/pager problem on MacOSX, Carlo De Falco, 2013/10/11
Re: gui/pager problem on MacOSX, Carlo De Falco, 2013/10/11