octave-maintainers
[Top][All Lists]
Advanced

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

Re: Octave GUI status


From: Michael Goffioul
Subject: Re: Octave GUI status
Date: Fri, 19 Aug 2011 10:12:30 +0100

On Fri, Aug 19, 2011 at 9:45 AM, Jacob Dawid <address@hidden> wrote:
> Hello maintainers!
> Although I was not posting recently, there is much going in Octave GUI.
> Andriy did great work pointing out usability bugs and even providing
> patches. He fixed encoding issues with the IRC client, too, and found bugs
> where I would never search for them ;) Beside a complete rewrite of the IRC
> backend, today I have cut out the whole view part of the terminal emulation,
> which was 23 files with difficult to maintain code. The problem with this
> view code was that it was drawing itself, which caused unnecessary problems.
> Instead, I replaced the terminal with a nice looking QPlainTextEdit, which
> integrates nicely and can't be recognized as being "foreign". It has to be
> polished though, so that every keypress is recognized correctly. This is how
> it looks:
> http://www7.pic-upload.de/19.08.11/ndyzdy1kyxiv.png
> Also, this means that the only thing what is left from Konsole is the Pty
> part (5 classes, of which all are strongly related (Pty, KPty, KPtyProcess,
> KProcess and KPtyDevice). In other words, from approximately 80 files that
> we incoorporated from Konsole in order to have it working, I have thrown out
> almost 70 files one after another.
> Now it's getting a bit complicated, so you have to read carefully: octave is
> already living in a thread in our program, so we have shared memory. The
> reason we still need to have Ptys is that octave outputs to std::out and
> std::err and seems to read from st::in for default. Because octave is part
> of our program (we linked against it), the output is gone once it has been
> sent. What we are doing right now is that we create a pty and redirect the
> entire std::out of our application back to our own terminal in the GUI,
> which is not a good idea, because we can't output to std::out anymore on
> other places in the application (if we do, the output will appear in the
> octave terminal).
> The conclusion is: If we want to get rid of ptys (in order to go
> platform-independent) it should work to have functions to pass octave
> streams it shall write to instead of std::out/std::err and read from a
> different stream instead of std::in. Before actually calling octave_main we
> could then set our own streams and that way interface octave the way we are
> doing it right now.
> What do you say?

What you're basically proposing is (similar) to run octave over regular pipes.
This is an approach I've used a few years ago under Windows and I've already
raised the associated problems. The main one is that octave stdin and stdout
are not tty's anymore and any process started from octave won't have regular
tty's either. So for instance the pager won't work anymore.

Whether or not this is considered as a problem is another story. Just be
aware of the consequences.

You might also have a hard time making CTRL-C to work fine without a tty,
especially in sub-processes.

Michael.


reply via email to

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