[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