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?