bugGNU Octave - Bugs: bug #44402, spurious undo button

 
 

bug #44402: spurious undo button

Submitter:  Carnë Draug <carandraug>
Submitted:  Sun 01 Mar 2015 07:39:47 PM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 25 Mar 2015 08:22:47 PM UTC, comment #11: 

Changeset
http://hg.savannah.gnu.org/hgweb/octave/rev/8f59e3cca4e7
removes the main button and renames the toolbar into "Toolbar". The toolbar can be hidden/shown by a right click on a widget title and the selection of "Toolbar".

Torsten Lilge <ttl>
Group Member
Mon 16 Mar 2015 07:20:59 PM UTC, comment #10: 


> The "new" and "open" are only used on text editor and already appear on the editor widget.


The editor might be hidden, tabbed under another widget, or a custom editor is in use. In these cases the buttons in the main window are quite useful.

> The copy, and paste buttons are like the undo buttons. They already appear on the editor for that use, and would be of little use on the command line.


These buttons are for all widgets. Moreover, while the use of the "undo" action is really limited to the current input line, it might be useful to copy some output from the terminal window.

> The current directory does the same as the bar on the file browser


Yes and no. The file browser can be synchronized with the octave directory. In this case both combo boxes show the same directory. In the other case, both directories can be used independantly or browsing files outside the current octave directory.

> May actually be a good idea to add a "browse directories" button next to the "One directory up" button on the File browser widget actually


The button is in the drop-down menu next tot he "up" button due to less space.

> This tab widget can float but can't be closed like the others so it will take up valuable space whether the user wants it or not.


I will check if the tool bar can be made closeable.

> The shortcuts for the command line are provided by readline and it seems to me that the GUI is capturing them. I just tried to define a few shortcuts on .inputrc and they all worked fine without gui. With the gui, they failed when they clashed


There is a preference for disabling the shortcuts of the gui in order to avoid conflicts with readline.

> The control-z shortcut is not a very good on the command line since without the GUI sends the process to the background.


The default shortcut for undo (and other actions) is the one that Qt provides as default for the target platform.

> We already a quite powerful library to control what happens at the prompt, and fully configurable.


I agree with you but I doubt that many users who are working with non-*ix systems are used to readline or .inputrc files.

Torsten Lilge <ttl>
Group Member
Mon 16 Mar 2015 02:21:18 AM UTC, comment #9: 

I think removing the button is a good idea. Looking at all the windows, the only windows where it could make sense is the editor and the documentation. Since the later always opens a new tab, then it's really only the text editor.

Taking a closer at the whole tab, seems to me like none of the buttons there are useful:

  • The "new" and "open" are only used on text editor and already appear on the editor widget.
  • The copy, and paste buttons are like the undo buttons. They already appear on the editor for that use, and would be of little use on the command line.
  • the current directory does the same as the bar on the file browser (may actually be a good idea to add a "browse directories" button next to the "One directory up" button on the File browser widget actually)
  • this tab widget can float but can't be closed like the others so it will take up valuable space whether the user wants it or not.


Because of this, I'd argue that we'd be better off without that tab. Here's a screenshoot of it http://picpaste.com/pics/Screenshot_from_2015-03-16_01_34_02-PQUkRgEM.1426471752.png

About the shortcut, I am unsure. The shortcuts for the command line are provided by readline and it seems to me that the GUI is capturing them. I just tried to define a few shortcuts on .inputrc and they all worked fine without gui. With the gui, they failed when they clashed. Example ~/.inputrc for testing:


Control-v: "shortcut V pressed"
Control-f: "shortcut F pressed"


The control-z shortcut is not a very good on the command line since without the GUI sends the process to the background. We already a quite powerful library to control what happens at the prompt, and fully configurable. Why have another one on top of it? Also, Control-C works fine as shortcut for "abort", but if there's text selected then it suddenly becomes a shortcut for "copy".

Carnë Draug <carandraug>
Group Member
Sun 15 Mar 2015 05:52:28 PM UTC, comment #8: 

What about removing the button but retaining the undo-action with the shortcut, it's menu entry and it's connection to the editor?

Torsten Lilge <ttl>
Group Member
Sun 15 Mar 2015 04:09:09 PM UTC, comment #7: 

We are making the GUI code more complicated with one more signal, and the interface more cluttered with another button, in order to support an undo button for the command line. Should we really be going that way?

An undo button makes sense when doing larger things. At the command line, undo can only change the line we are currently writing which makes it even more useless.

Sure, there may be someone who will prefer to move the mouse and click the icon when at the terminal but I doubt that it will be true for the vast majority. We will just be making the interface more complicated for them. And when will there be enough buttons to do small things? Readline has a lot more stuff which I hope will not be turned on buttons too.

Carnë Draug <carandraug>
Group Member
Sun 15 Mar 2015 03:50:51 PM UTC, comment #6: 

Works for me, thanks Torsten.

Mike Miller <mtmiller>
Group Member
Sat 14 Mar 2015 06:07:34 PM UTC, comment #5: 

I have pushed changeset
http://hg.savannah.gnu.org/hgweb/octave/rev/f7a805f02723
which emits a signal on the undo action of the main window if the terminal does not have focus. This signal is used by the editor to trigger it's own undo action when an editor tab has focus.


Torsten Lilge <ttl>
Group Member
Sun 08 Mar 2015 05:13:03 AM UTC, comment #4: 

I agree with Dan that the command window should be kept as minimal as possible. And agree that undo seems to make sense next to copy and paste buttons.

I also agree that the undo button is of minimal usefulness on the command window. But I'm probably not a good one to judge the utility, some users may well prefer clicking an undo button to clear the input line rather than some keyboard combination.

As to the dual undo buttons when the editor window is active: I think the undo button in the main toolbar should maybe be linked to the editor when the editor is active. This seems to be the way the two sets of copy and paste buttons are handled, but not undo for some reason.

Ok to repurpose this to link the main window undo button to the editor undo when the editor is active?

Mike Miller <mtmiller>
Group Member
Sun 01 Mar 2015 08:51:59 PM UTC, comment #3: 

Good questions.  The undo button for the command line probably isn't something I'd find that useful.  It can only undo a portion of a line and if there is a shortcut key I'd rather use that.  I'm indifferent to it.  I don't think it is worth putting icons atop the command line window because that is just using valuable space for little return.  Not sure, I could be fine with icons above individual windows--I'd have to see it.  Kind of short notice.  Maybe wait to get feedback from users then change if necessary.

But the Undo goes with the copy/paste operation so if those two are kept then might as well keep the Undo--unless you think Undo should be removed from the dropdown menu as well.

Clear command-window-seems a more icon-worthy action, but there is a right click menu for access to clear-command-window.

Dan Sebald <sebald>
Sun 01 Mar 2015 08:07:41 PM UTC, comment #2: 

I was very surprised and tried to revert a command (after pressing enter) expecting to revert a variable to the previous state. Only then did I understood that it only changes the entered text.

If this button only has an effect on the command line window, then it should be part of the command line window (like the undo and redo buttons of the text editor). Also, we have an undo for the command line, should we also have redo button for it?

Also, is this really useful? Have a button to do stuff on a terminal and when we already have a "C-_" shortcut for it given by readline?

Carnë Draug <carandraug>
Group Member
Sun 01 Mar 2015 07:57:01 PM UTC, comment #1: 

Undo icon in the main window works for the command line.  I suppose the undo icon should be greyed when the command line window doesn't have focus.

Dan Sebald <sebald>
Sun 01 Mar 2015 07:39:47 PM UTC, original submission:  

I just gave the GUI a quick go and found that there is an extra undo button.  One on the main toolbar and is always present, and another on the tab that shows up when on the editor window.

Since the undo button is only used for the editor, should it be limited to that toolbar and window? See a screenshoot at http://picpaste.com/Screenshot_from_2015-03-01_19_36_38-KBCnC1jK.png (or the attached file, they are the same)

Carnë Draug <carandraug>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by carandraug (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-03-15 mtmiller StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2015-03-14 ttl StatusNone Ready For Test
    2015-03-01 carandraug Attached File- Added Screenshot from 2015-03-01 19:36:38.png, #33222

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code