From graphics-request at octave dot org Tue Feb 28 19:44:45 2006 Subject: Re: GUI thoughts From: "John W. Eaton" To: "Sebastien Loisel" Cc: "octave graphics and gui mailing list" Date: Tue, 28 Feb 2006 20:44:35 -0500 On 28-Feb-2006, Sebastien Loisel wrote: | I have answers to some of your questions. But lemme make a comment 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. Size is not the only concern. Even if you only need a few lines of code to do something that Octave already does, it seems likely that the two implementations will diverge. Octave changes over time. Bugs are fixed. It seems to me that it would be much better to not duplicate code from Octave in the GUI. | 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. But why should you have to do all that? It seems to me you are implementing your own (limited?) terminal widget, specifically for this GUI project. Wouldn't it be much better to use an existing terminal widget that hides all of these details, provides more features, lets Octave work as it normally does in an interactive terminal, and that you would not have to maintain? | 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=i;klinebuf[k]; } | settings.setValue("linebuf",save); | | This doesn't call into any of my own code, it's all QT code. So it really is | two lines of code to save the history buffer. So you have a history buffer separate from the one that Octave would maintain using readline (via the comand_editor class)? That means that Octave's history, edit_history, and run_history commands and the history_file, history_size, and saving_history variables don't do what users expect unless you rewrite them to use the GUI 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. What | does it do? I don't remember precisely everything that is affected. I think it turns off command editing and history and omits timestamp checks for function files (a prompt is not printed, so why should we check for upated files)? | > 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 up | pause() and functions of that sort so that events get processed. But if Octave is off doing some long calculation (say in a Fortran function) then nothing is printed and eval_string doesn't return until the calculation is complete, so the GUI won't respond. Perhaps that's the way Matlab works too, but it doesn't seem acceptable to me. | 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 what | Kalle is working on. Which is what you said afterwards. Ok. OK. If people are working on things that involve Octave internals (and I don't see how threading could not) then they should be posting ideas about implementations here. I saw one proposal from John Swenson about passing data to and from Octave, but I'm not sure that this is really what we are looking for. The proposal was to check in a few locations like the main loop or anywhere a breakpoint can be set, but that doesn't help with long-running calculations in compiled code. Octave would still be unresponsive during those times. | If you want to make Octave thread-safe, that would kick ass, however if I | were tasked with doing it I would be apprehensive. Why? Is it because you are unfamiliar with Octave internals, or something else? I'm familiar with the internals, but don't know much about threads. Is it possible to use (approximately the same threading model (whether or not it is precisely the same set of function calls) on POSIX and Windows systems? jwe