Re: GUI release date approaches

[Daniel J Sebald]

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