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

[Rik]

On 10/29/2013 11:09 PM, John W. Eaton wrote:
> 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.

I'm mostly seeing this, but with one more oddity.  If I type 'run-octave
--no-gui' the prompt at the CLI is "octave".  Similarly if I use
'run-octave --no-gui-libs' the prompt is "octave".  But, if I add an
additional option for processing, then the prompt changes to "octave-gui"
or "octave-cli".  So, 'run-octave --no-gui -f' produces the the prompt
"octave-gui".  At first I thought this was mostly about what we were
putting in to the 0th argument for exec, but I think there might be more to
it.  If I use 'run-octave --no-gui' then Ctrl-Z behavior works.  If I add
extra arguments so that octave-gui is definitely invoked, then I see the
problem with Ctrl-Z detailed above.

>
> 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?
>
Not uigetfile, but weren't the dialog boxes such as errordlg, warndlg, etc.
working from the command line as long as Qt was available?

--Rik