Re: Qt/gui on MacOSX (was: 4.0 release goals)

[Ben Abbott]

On Nov 5, 2012, at 3:50 PM, Michael Goffioul wrote:

> On Mon, Nov 5, 2012 at 3:45 PM, Ben Abbott <address@hidden> wrote:
> Octave exists during the call "QApplication application (argc, argv);"  at 
> line 87 in libgui/src/octave-gui.cc
> 
>  80 int
>  81 octave_start_gui (int argc, char *argv[])
>  82 {
>  83   dissociate_terminal ();
>  84
>  85   setenv ("GNUTERM", "qt", 1);
>  86
>  87   QApplication application (argc, argv);
> 
> With lack of experience with c++, I don't know how to go further.
> 
> It looks like yet another hard limitation of Mac OS X. If Qt decides to exit 
> the app, there's probably a good reason for it, and it's also probably 
> difficult (or impossible) to work around as-is. You might try to debug 
> further with debug version of Qt, but I'm not sure it's worth. Now I'm 
> wondering what can be done to make it work under Mac OS X. Maybe we should 
> simple re-exec octave with a specific flag to avoid re-forking?
> 
> Michael.

Gnuplot overcame the same (similar?) problem.  I asked Ethan Merritt for an 
overview.  See below.

> On Sunday, 04 November 2012, you wrote:
>> Ethan,
>> 
>> Octave's developers are planning to introduce a Qt based GUI/IDE soon.  At 
>> the moment it does not run on MacOS.  I'm not intimately involved in that 
>> development, but have the impression that Gnuplot had a similar problem with 
>> its Qt terminal.
>> 
>> Octave's GUI/IDE did run on MacOS X when it was compiled independently, but 
>> since theGUI/IDE was integrated into the CLI code base it no longer runs.  
>> Instead we get the errors below.
>> 
>> The process has forked and you cannot use this CoreFoundation functionality 
>> safely. You MUST exec().
>> Break on 
>> __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__()
>>  to debug.
>> Do you know the details of what was needed to get the Gnuplot qt terminal to 
>> run?  Or, can you point me to some one who does?
> 
> Yes.  
> OSX apparently has two hard restrictions that both seem overly severe
> to people familiar with normal [li/u]nix practice:
> 
> 1) As the message states, the only legal operation after forking is to 
> immediately
>   exec().  Well, I don't know how "immediate" that is, but certainly you 
> cannot
>   execute standard library calls before exec().
> 2) The event loop for writing to the graphics library must be in the main 
> process,
>   it cannot be in a separate thread or child process.
> 
>> I'm looking for is a simple high level description of what the problem was 
>> and how it was fixed.
> 
> So the fix, if you can call it that, is to write a separate program that
> executes the graphics commands.  The main process then does fork() + exec() to
> run that separate process, and communicates via a pipe.
> 
> In gnuplot's case, the relevant bits of qtterminal are built into
> a separate executable gnuplot_qt that acts as an outboard driver
> analagous to gnuplot_x11.  Both manage the graphics output in response
> to commands piped from gnuplot proper.
> 
>       Ethan

Ben