octave-maintainers
[Top][All Lists]
Advanced

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

Re: error building GUI on Mac OS-X 10.6.8


From: Ben Abbott
Subject: Re: error building GUI on Mac OS-X 10.6.8
Date: Mon, 18 Feb 2013 08:06:54 -0500

On Feb 17, 2013, at 11:33 PM, John W. Eaton wrote:

> On 08/11/2012 01:06 PM, Michael Goffioul wrote:
>> On Sat, Aug 11, 2012 at 5:53 PM, John W. Eaton <address@hidden
>> <mailto:address@hidden>> wrote:
>> 
>>    On 11-Aug-2012, Ben Abbott wrote:
>> 
>>    |
>>    | On Aug 11, 2012, at 12:13 PM, Michael Goffioul wrote:
>>    |
>>    | > On Sat, Aug 11, 2012 at 3:53 PM, Ben Abbott <address@hidden
>>    <mailto:address@hidden>> wrote:
>>    | >> The the "thread" subdirectory references removed
>>    | >
>>    | > OK, but if you remove moc_QTerminal.cpp and let moc recreate it
>>    )when run from gui/src/), does it contain a reference to thread again?
>>    |
>>    | You are correct. The moc_QTerminal.cpp is recreated but without
>>    the "thread" reference.
>>    |
>>    | I did this a second time to verify.  Now when I ./run-octave the
>>    gui comes up!
>>    |
>>    | So what I did was ...
>>    |
>>    | (1) Apply the findFirst.diff patch
>>    | (2) Commented out out the call to dissociate_terminal in
>>    octave_start_gui in gui/src/octave-gui.cc.
>>    | (3) Removed qterminal/libqterminal/moc_QTerminal.cpp
>>    | (4) Ran "make"
>>    |
>>    | I'm able to type commands and plot, and don't see any focus
>>    problems.  However, the keyboard mapping isn't correct.  When "less"
>>    is paging the output, typeing "q" has no effect.  Neither does
>>    ctrl-c.  The "Quit" from the MacOS menu bar also does not work.  So
>>    I had to kill Octave from the MacOS activity monitor.
>> 
>>    OK, can you try the following change and see if it helps?
>> 
>>    If this change works, then we would need to find a way to call
>>    dissociate_terminal earlier.  But I'd prefer to avoid calling it
>>    unconditionally.
>> 
>>    Even if this change does work, it might be best to find a way to
>>    associate the keyboard (/dev/tty?) with the command window without
>>    having to fork.
>> 
>> 
>> That's what I try to achieved when I looked at it, but didn't succeed.
>> The reasoning was the following:
>> - to change the controlling terminal, one can call ioctl with TIOCSTTY
>> - the above is only possible if the calling process is a session leader
>> - to become a session leader, one can use setsid
>> - setsid requires the calling process not to be a group leader
>> - the recommended way to use setsid is to fork
>> 
>> As I mentioned in one of my previous mail, low-level Linux expert needed.
> 
> I think what we need to do is give up the controlling terminal.
> 
> I remember that Jacob noted that "more" worked and "less" failed.  I did some 
> poking around, and less will try to read keyboard input from /dev/tty if it 
> can open that, otherwise it uses stderr (!) which seems to be some old Unixy 
> behavior that just happens to work.  Without the fork, opening /dev/tty 
> succeeds, but it is not associated with the QTerminal window.  After the fork 
> and the call to setsid, opening /dev/tty fails and less tries to use file 
> descriptor 2 (stderr) and that works, because we've set up the stdin, stdout, 
> and stderr file descriptors so that they are connected to the slave process 
> (Octave running in the separate thread, connected with the pty).  Forking 
> doesn't matter for more because it always reads from file descriptor 2.
> 
> On OS X, does the attached patch cause less to work correctly in the Octave 
> terminal window?  The call to ioctl is supposed to give up the controlling 
> terminal.  It makes less work for me without the fork+setsid call.  
> Unfortunately, exiting Octave now crashes when the QTerminal object is 
> deleted.  So although this change may provide a clue, it is not the ultimate 
> solution.
> 
> The #ifdefs that I used are probably not ideal either.
> 
> Also, I now see that with either the fork+setsid call or the calls to ioctl, 
> calling
> 
>  system ("emacs -nw")
> 
> fails with a message about not being able to open /dev/tty.  So neither of 
> these solutions really seems right.  We really want to have a terminal widget 
> that can run any program and properly handle I/O...
> 
> jwe
> <diffs.txt>

John,

Since building the GUI build system was integrated into autotools, the GUI no 
longer runs on MacOS X (it does build).  There are a couple threads on this, 
but as far as I know none of us are working on it.

        
https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2012-November/030657.html

        
https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2012-November/030673.html

My impression is that changes can be made to allow the GUI to run on MacOS 
(since it did work when built via qmake). 

Regards
Ben

p.s.

 I am skeptical the JAVA stuff can work on MacOS X.  MacOS X's design requires 
that GUI updating be done in the main thread.  The details are beyond me, but I 
did find the discussion below.

        
http://www.cocoabuilder.com/archive/cocoa/315103-why-is-the-threading-and-ui-updating-designed-to-be-done-only-on-main-thread.html




reply via email to

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