octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ctrl-Z not working correctly with --no-gui option


From: John W. Eaton
Subject: Re: Ctrl-Z not working correctly with --no-gui option
Date: Wed, 30 Oct 2013 02:09:25 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12

On 10/29/2013 06:03 PM, Rik wrote:
10/29/13

jwe,

When I use 'run-octave --no-gui' from a shell I get a CLI interface.
However, if I suspend the program with Ctrl-Z I get occasional printings of
the octave prompt while I am working in the shell.  This doesn't happen if
I use '--no-gui-libs'.

I think the strange behavior was due to a botched test in the main
program in main.in.cc that caused Octave to fork+exec instead of just
exec when not running the gui.  I fixed that problem in this
changeset:

  http://hg.savannah.gnu.org/hgweb/octave/rev/0b81d65d3c49

However, signals are still not working properly.  For example, try
starting Octave with --no-gui and then type Ctlr-Z.  I expect that it
won't respond.  Now type another character.  That will suspend
Octave.  If you resume it, then the character you previously typed
should be pending as input at the prompt.

If instead of calling

  main_thread.start ();

I just print "hello world", then the Qt event loop starts and the
program responds to Ctrl-Z, so perhaps the problem is happening
because Octave is running in a separate thread?

Based on the description of the QCoreApplication class, I checked in
one additional change so that if the GUI is not started, then we use
QCoreApplication instead of QApplication.  I think that's the right
thing to do, but if anyone knows for sure, please speak up.

Finally, since we don't really have the non-gui version of Octave
working with Qt-based widgets for things like uigetfile, maybe we
should just start octave-cli when --no-gui is specified?

jwe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]