Re: Some issues with recent GUI version

[Daniel J Sebald]

On 04/16/2013 03:11 PM, PhilipNienhuis wrote:
> John W. Eaton wrote
> > On 04/15/2013 06:18 PM, John W. Eaton wrote:
> > > On 04/14/2013 03:52 PM, PhilipNienhuis wrote:
> > >
> > > > - One can all too easily change variable names in the workspace browser.
> > > > Presently all that is needed to foobar variable names is having
> > > > clicked on
> > > > the workspace pane, with the focussed variable possibly scrolled out of
> > > > sight, and start typing an Octave command, assuming it'll end up in the
> > > > command window.
> > > > I'd rather have it so that one needs to first right click on a
> > > > variable name
> > > > and then explicitly select "Rename", only working for that one
> > > > right-clicked
> > > > variable.
> > >
> > > I thought that it was necessary to double click to enter an "edit" mode,
> > > but I see that highlighting is enough to allow the entire contents of
> > > the variable name field to be replaced. Is there some easy way to
> > > disable that, and not enter edit mode without the double click?
> > > Alternatively, I don't have a problem with restricting this action to a
> > > context menu because I don't think that renaming variables is a really
> > > common thing to do. Am I wrong? Do people really use this feature often?
> > >
> > > Another related issue is that copying to the clipboard doesn't seem to
> > > work for me unless I'm in edit mode. I'd expect to be able to copy the
> > > contents of the cell without entering edit mode. I can add a context
> > > menu item for copy, but I don't know how to make copy work directly from
> > > the table cell.
> >
> > I checked in the following change.  Is the new behavior with this change
> > better?
> >
> >     http://hg.savannah.gnu.org/hgweb/octave/rev/dbc7018be4be
>
> Thanks, yes it is.
>
> I would perhaps slightly prefer typing a new variable name in the cell in
> question in the workspace browser itself (it is now in a separate pop-up),
> but as you wrote, renaming variables doesn't occur too often.
>
> To be honest, although I do admit this is a handy feature, I'm surprised it
> has been implemented at all. It leaves no trace in the history so tracking
> or reconstructing how one has obtained some specific result only gets more
> troublesome; the more so if it happens unnotedly as I described.
> So I'm glad you made this renaming-behind-the-scenes a bit harder to do.

This is generally true about GUI's.  When someone uses some GUI tools to 
modify a plot's decorations and then prints that, there's no trace of 
exactly what was done to create the plot.  That's why I've always been 
content writing script files and processing those.  It's not as fast a 
process, but it is reproducible, which has its advantages for someone 
who does a lot of repetitive tasks in their work.

You raise a couple good points though.  One hints to the advantage of 
using Octave's existing commands to modify data.  Those commands can be 
put into the history.  There are some worthwhile distinctions of 
operations to make.  For example,

Command-line-initiated operations:  These already have the command going 
into history and affect GUI appearance.  These would be dbstop, dbclear, 
and similar commands.  The signal/slot mechanism seems a good candidate 
for that.  There are immediate effects in the GUI.

GUI-initiated operations that modify Octave workspace memory:  I think 
constructing the equivalent Octave command and queuing it for the Octave 
core and placing the command in history seems worth considering.

GUI-initiated operations that only inquire about Octave workspace 
memory: Similar to the above, but in this case no command needs to go in 
history because nothing alters the workspace.  Setting breakpoints, 
clearing breakpoints, dbstatus, etc. don't really need to be recorded as 
part of history.  At some point that becomes self defeating in a 
debugger because there is more background activity than there is 
processing commands and would make for a messy history record.

Dan