Re: gui/pager problem on MacOSX

[Michael Goffioul]

On Fri, Oct 11, 2013 at 11:14 AM, John W. Eaton <address@hidden> wrote:

On 10/11/2013 11:01 AM, Ben Abbott wrote:

On Oct 11, 2013, at 10:54 AM, John Swensen wrote:

On Fri, Oct 11, 2013 at 10:32 AM, Ben Abbott<address@hidden>  wrote:
On Oct 11, 2013, at 9:58 AM, John W. Eaton wrote:

On 10/11/2013 09:47 AM, Ben Abbott wrote:

I just noticed that when running the gui on MacOSX the pager isn't working. When less is waiting on input, typing at the keyboard has no effect.  The only way to recover is to pull up the task manager and kill Octave.

Carlo, can you verify that this isn't a problem local to my build (or maybe MacOSX 10.7?)

How are you starting Octave?  If it is from a terminal, does it work to type the commands for less in the terminal window?

jwe

I run the gui using run-octave.

 From the terminal the pager works correctly.

Ben


Way back when I was actively working on OctaveDE in GTK and later the QT version of it, JWE helped me get some PTY magic working so that the gui terminal was the controlling terminal.

You can see the code that had to happen at startup to fork and make it work at
http://sourceforge.net/p/octavede/code/HEAD/tree/branches/OctaveDE_QT/src/main.cpp
I don't understand this code completely, but without it the pager would not work in the gui. Before this fix, if I launched the gui from a terminal, I was able to go back to the terminal from which it was started and control the pager that was in the QT gui terminal. I'm not sure if this is still a good/right solution, but thought I would chime in nonetheless.

John Swensen

Thanks John! ! !

Your suggestion worked. The pager is connected to the original terminal window.

Yes, but it should not be.  It should work inside the GUI terminal.

The problem is that on OS X we don't execute the code that forks because OS X won't let us do that and then set up the Qt event loop.  So this problem is still not solved for OS X.

I'm not entirely sure, but wasn't the problem the fact that OS X refused to fork/exec if the base process had already accessed the cocoa framework, which we do (or used to do) through the display_info class?

Michael.