Re: GUI release date approaches

[John Swensen]

The very old octave_server class that I used in OctaveDE used a synchronous interaction between the GUI and the octave core during the readline idle loop to query specific variables. Essentially the GUI would maintain a list of mutex-protected requested variable names and Octave would read it and push a copy of the variable back through a mutex-protected list of variables. I know this kindof goes against the new asynchronous paradigm for GUI/Octave interaction that has come with the QT GUI, but it made for an easy way to retrieve things like this for tooltips.  And because the idle loop is many time per second and only runs when not executing code, it was fairly efficient also. The GUI, then, just had to be smart about what and when it was requesting a full variable.

On Tue, Jun 11, 2013 at 3:30 PM, Daniel J Sebald <address@hidden> wrote:

On 06/11/2013 01:21 PM, Torsten wrote:

On 09.06.2013 23:42, Daniel J Sebald wrote:

JWE had set a goal deadline for a GUI release as the end of June.  I'm
sure there will be and typically always is more work to do, but
generally the GUI is running pretty well under my system.  Everyone
should test things real well and note any small, easily fixable quirks
like a missing "setfocus()" that would improve workflow for the user.
For example, I think I would like to have the debug/break operation set
the focus of the file in which the break occurred rather than remain at
the command window.

There is one thing that I think that should be added still and it is the
variable "editor" or not necessarily editor but "variable viewer".  John
made a try at that, and anything even rudimentary would be nice.  The
reason I say that is that breakpoints just seems unfinished without such
a thing.  From the user's standpoint it is like, "Ok, hit a breakpoint,
now what?"  The right-mouse-click-option "disp (VAR)" doesn't seem to
work (two things, a semicolon is placed after the "disp (VAR);" so that
the contents aren't actually displayed in the command window, and also
the debugger seems to leave debug mode), but more than that I think
going back and forth between the editor and command window to see a
variable's contents isn't as nice as having the code and variable
contents visible at the same time.  The nicest would be positioning the
cursor over a variable and it's value appears in the tool tip...down the
line maybe.

The tooltip for variables is a good idea.
Attached a patch that implements a custom tooltip in the editor. At the
moment the tooltip just shows the word found under the mouse pointer.

Oh, that has potential.  Nice.

What would be the best way to get the actual names and values of valid
variables?

I had created a patch that will issue a command in the background and produce, if I remember correctly, the result of the command and the error status of the command.  It's not available right now, but basically all that would be needed is:

1) issue a command which is the name of the variable

2) if there is no error, take the result of the command (which will be a text string) and dump it into the tooltip, it should already have the formatted similar to what typically would go to the pager (if an error, i.e., Octave doesn't know about that variable, then no tool tip)

3) however, if the size of the text is too big, say more than 1000 characters, then maybe just display "variable too big" or something similar to avoid displaying a 100x100 array in a tooltip for example

There would be a lot of background activity as someone keeps moving the cursor about over text.  Without knowing how much CPU that consumes, perhaps an option to turn that off would be good.

Anyway, the feature depends on the ability to do background commands.

Concerning the workspace viewer: A semicolon has no effect for disp(),
it always displays its argument. There must be another issue preventing
the output and leaving the debug mode. Maybe the used callback
main_window::execute_command_callback where the command editor event
loop is used?

OK, I'm not sure then.

Related to this: Should a double click on a row of the workspace viewer
call disp() for the variable until we have a variable editor?

Well, maybe.  I suppose we should figure out what the problem is with leaving debug mode when using disp() before deciding that because if there is something inherently problematic with that, then I'd say "no".

Dan