From graphics-request at octave dot org Tue Feb 28 16:46:58 2006 Subject: Re: GUI thoughts From: "Sebastien Loisel" To: "John W. Eaton" Cc: "octave graphics and gui mailing list" Date: Tue, 28 Feb 2006 23:45:22 +0100 ------=_Part_7346_10977336.1141166722387 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline John, I have answers to some of your questions. But lemme make a comment first. I= n many of your emails you are concerned about code duplication, but then you mention something that takes up only a small fraction of my code. The two largest files in Workshop are editwindow.cpp at 457 lines of code (the .m file editor), and mainwindow.cpp at 301 lines of code (sets up the main window, menus, tabs, restores the window configuration, opens editors, help application, etc...) The code you keep talking about is myconsole.h at 35 lines of code and myconsole.cpp at 198 lines of code. And of the 198 lines of code in myconsole.cpp, most aren't concerned with octave stuff. Indeed, the only reason myconsole.cpp is 198 lines of code is because of the hoops = I jump through to prevent the cursor from going somewhere weird. My console widget is secretly a text editor, and if I'm not careful, the user ends up writing text where he shouldn't. With that said... On 2/28/06, John W. Eaton wrote: > > In Sebastien's Octave Workshop, I think the GUI handles all events Yes. grabbing std::cout in some way. This sort of works, but misses a few > things like handling the diary, automatic function updating based on > the last prompt time, the actual readline library for command-line Most of the 233 LOC in myconsole.h/.cpp are because I am subclassing a text editor widget and then trying to prevent the cursor from going somewhere weird. The bits that you mention specifically like history buffer and readline functionality are veeeery tiny. For instance, saving the history buffer from one session to the next is this code: for(k=3Di;klinebuf[k]; } settings.setValue("linebuf",save); This doesn't call into any of my own code, it's all QT code. So it really i= s two lines of code to save the history buffer. Octave session (for one thing, embedding Octave this way turns off the > internal flag that tells it that it is running in an interactive > session). You could probably work around that too, but I think there > must be a better way. This I'm curious about because it's the first time I hear of this flag. Wha= t does it do? Also, if you are embedding Octave with eval_string, I think your GUI > will be unresponsive while Octave is performing computations. Unless Yes and no. Basically it's very close to Matlab in terms of responsiveness. Each time Octave prints anything, it ends up immediately (modulo buffering) in my GUI and my GUI takes that opportunity to handle events, check for CTRL+C, and so on. So the GUI isn't entirely dead during Octave execution. One thing I don't yet do, but you imagine it's not hard to do, is to hook u= p pause() and functions of that sort so that events get processed. you are running Octave in a separate thread, I think you have to wait > until eval_string returns to continue with the GUI operations. If you That's not correct. I will have to wait until eval_string returns before I interact with Octave again, but the GUI itself can keep going. Which is wha= t Kalle is working on. Which is what you said afterwards. Ok. To avoid threads, you could start Octave as a coprocess to your GUI, but you will still need some modifications to Octave so that it can > process requests while it is off running user code. You won't want to Right, so as long as those modifications aren't made, there's little point in doing it in a coprocess. And when these modifications are made, there's no reason why a thread couldn't make use of it. that this can be done, but it will mean some extra effort. Will you > parse text data or design a protocol for passing binary data? Will One of my priorities is to avoid this sort of stuff. And I don't think usin= g MPI to communicate with the GUI that's on the same CPU is particularly smart. instead of spawning a subprocess, you set up some ptys, dup some file > descriptors, start Octave in a separate thread, then attach the master > pty to the terminal widget. This might be possible in Windows too, and is something I will need to investigate anyway for other reasons I don't want to discuss right now. * Should we work to make Octave thread-safe? I think I would prefer > to work on this instead of a protocol that could be used to > communicate with a separate Octave process. If you want to make Octave thread-safe, that would kick ass, however if I were tasked with doing it I would be apprehensive. But definetly, if you do it I'll use it. 100%. The earlier the better. * Is there a terminal widget for Qt that could do the same thing as > VTE? I don't really want a GUI for Octave to be useful with just I haven't found one. I looked for a few hours one afternoon recently. (Yesterday?) S=E9bastien Loisel ------=_Part_7346_10977336.1141166722387 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline John,

I have answers to some of your questions. But lemme make a com= ment first. In many of your emails you are concerned about code duplication= , but then you mention something that takes up only a small fraction of my = code. The two largest files in Workshop are=20 editwindow.cpp at 457 lines of code (the .m file editor), and mainwindow.cp= p at 301 lines of code (sets up the main window, menus, tabs, restores the = window configuration, opens editors, help application, etc...) The code you= keep talking about is=20 myconsole.h at 35 lines of code and myconsole.cpp at 198 lines of code. And= of the 198 lines of code in myconsole.cpp, most aren't concerned with octa= ve stuff. Indeed, the only reason myconsole.cpp is 198 lines of code is bec= ause of the hoops I jump through to prevent the cursor from going somewhere= weird. My console widget is secretly a text editor, and if I'm not careful= , the user ends up writing text where he shouldn't.

With that said...

On 2/28/0= 6, John W. Eaton < jwe at bevo dot che dot wisc dot edu> wrote:
In Sebasti= en's Octave Workshop, I think the GUI handles all events

Yes.

Oct= ave session (for one thing, embedding Octave this way turns off the
inte= rnal flag that tells it that it is running in an interactive
session).  You could probably work around that too, but I thi= nk there
must be a better way.

This I'm curious abo= ut because it's the first time I hear of this flag. What does it do?

Also, if you are = embedding Octave with eval_string, I think your GUI
will be unresponsive= while Octave is performing computations.  Unless

Yes and no. Basically it's very close to Matlab in te= rms of responsiveness. Each time Octave prints anything, it ends up immedia= tely (modulo buffering) in my GUI and my GUI takes that opportunity to hand= le events, check for CTRL+C, and so on. So the GUI isn't entirely dead duri= ng Octave execution. One thing I don't yet do, but you imagine it's not har= d to do, is to hook up pause() and functions of that sort so that events ge= t processed.

you= are running Octave in a separate thread, I think you have to wait
until= eval_string returns to continue with the GUI operations.  If you

That's not correct. I will have to wait until eval_st= ring returns before I interact with Octave again, but the GUI itself can ke= ep going. Which is what Kalle is working on. Which is what you said afterwa= rds. Ok.

To avoi= d threads, you could start Octave as a coprocess to your GUI,
<= blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 2= 04, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> but you will still need some modifications to Octave so that it can
proc= ess requests while it is off running user code.  You won't want t= o

Right, so as long as those modifications aren't made,= there's little point in doing it in a coprocess. And when these modificati= ons are made, there's no reason why a thread couldn't make use of it.

that th= is can be done, but it will mean some extra effort.  Will you
parse text data or design a protocol for passing binary data?  Wi= ll

One of my priorities is to avoid this sort of stuff= . And I don't think using MPI to communicate with the GUI that's on the sam= e CPU is particularly smart.

ins= tead of spawning a subprocess, you set up some ptys, dup some file
descr= iptors, start Octave in a separate thread, then attach the master
pty to the terminal widget.

This might be possible= in Windows too, and is something I will need to investigate anyway for oth= er reasons I don't want to discuss right now.

  * Should we work to make Octave thread-safe?  I think I wo= uld prefer
    to work on this instead of a protocol= that could be used to
    communicate with a separate Octave process.

If you want to make Octave thread-safe, that would kick a= ss, however if I were tasked with doing it I would be apprehensive. But def= inetly, if you do it I'll use it. 100%. The earlier the better.

&nb= sp; * Is there a terminal widget for Qt that could do the same thing a= s
    VTE?  I don't really want a GUI for = Octave to be useful with just

I haven't found one. I looked for a few hours one aft= ernoon recently. (Yesterday?)

S=E9bastien Loisel

------=_Part_7346_10977336.1141166722387--