Re: Detaching from terminal and keyboard input for GUI

[Michael Goffioul]

On Mon, May 6, 2013 at 5:32 PM, John W. Eaton <address@hidden> wrote:

On 05/01/2013 02:37 AM, John W. Eaton wrote:

On 05/01/2013 02:33 AM, John W. Eaton wrote:

On 05/01/2013 02:03 AM, John W. Eaton wrote:

On 05/01/2013 12:08 AM, Ben Abbott wrote:

On Apr 8, 2013, at 12:19 AM, Ben Abbott wrote:

For anyone interested, I'm currently able to build and run the GUI on
MacOS X without any extra patches.

Qscintilla is not yet working for me, but I haven't had the time to
determine why.

Ben

Using macports for dependencies and with the attached patch, the GUI
runs on MacOS 10.7.5. I'm presently using qscintilla 2.4.6.

Interesting, I thought I had tried something like that and it didn't
work for me. But it does seem to work for me on my Debian system, so
I guess whatever I was trying before was different. I checked in the
following changeset:

http://hg.savannah.gnu.org/hgweb/octave/rev/49832f60282e

Thanks!

Now I see that the ioctl call works when I start Octave from a desktop
launcher, but not when I start it from a shell running in a terminal.
Weird, I thought I just tested that. I must be losing my mind.

AFAIK, a simple ioctl() call only works if the calling process if session leader (that's the first approach I tried when I worked on it). But a process is not session leader when started from a terminal (I think the shell process is). That's why the fork was needed: to make octave a real session leader, allowing to detach from the controlling terminal.

 

D'oh, never mind, it was just a case of pilot error.

With this change, using less as the pager in the GUI command window
seems to be working OK for me.

But Ctrl-C does not work properly, nor do keyboard shortcuts like
Ctrl-O (for open file).  Neither of these do anything in the command
window.  Ctrl-C in the terminal where I start Octave does interrupt
Octave, but Ctrl-O does not work there either.

As a result of the change above, I suspect octave is not forked anymore, the terminal where you started it stays the controlling terminal; hence CTRL-C in that terminal as sent directly to octave as SIGINT. CTRL-O does not correspond to any signal, so nothing happens.

Does CTRL-O work when you focus another widget than the embedded terminal widget?

 

With the MinGW Windows build, Ctrl-C does work in the command window,
but Ctrl-O performs the readline command "operate-and-get-next"
instead of working as a shortcut for the file menu item "open".

I can confirm that. But strangely enough, if you focus another widget, and use CTRL-O, the "open" dialog pops up, which is normal. Then if you focus back the terminal widget and use CTRL-O, both actions happen: the dialog pops up *and* the readline operate-and-get-next is executed.

I would expect that if a global shortcut was installed, then the key-sequence wouldn't reach the focused widget. But this may be due to how readline operate. IIRC, readline configure stdin such that input is not buffered; hence readline receives keys as they are pressed. So by the time CTRL-O is interpreted by Qt and the global shortcut is executed, the individual CTRL and O keys have already reached readline.

Michael.