octave-maintainers
[Top][All Lists]
Advanced

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

Octave GUI status


From: Jacob Dawid
Subject: Octave GUI status
Date: Fri, 19 Aug 2011 10:45:33 +0200

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?

Jacob
--
Software Development == Church Development
Step 1. Build it.
Step 2. Pray.

Whitespace - the most ink saving programming language: http://compsoc.dur.ac.uk/whitespace/index.php .


reply via email to

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