bugGNU Octave - Bugs: bug #57220, Ctrl+C does not interrupt loops or...

 
 

bug #57220: Ctrl+C does not interrupt loops or demo sessions anymore

Submitter:  Pantxo Diribarne <pantxo>
Submitted:  Wed 13 Nov 2019 01:59:14 PM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 29 Apr 2022 01:42:23 PM UTC, comment #14: 

just to be sure that it's not related to the 7.1 preferences settings, is the option "Disable global shortcuts when Command Window has focus" checked or unchecked and does changing this setting alter the behavior you see? The option can be found under Edit / Preference - Shortcuts.

Nicholas Jankowski <nrjank>
Group Member
Fri 29 Apr 2022 10:15:59 AM UTC, comment #13: 

Thanks for your report @valeriumik.

I assume you run the Octave GUI.  If you put the focus back to the Octave Command-Window, does CTRL+C work again?  For me this works on openSUSE Linux 15.3.

Leaving item closed until getting a reply from @valeriumik.

Kai Torben Ohlhus <siko1056>
Group Member
Mon 25 Apr 2022 04:15:09 PM UTC, comment #12: 

Code:
  while 1
    [mouse_x, mouse_y, mouse_button] = ginput(1);
  end

in this loop CTRL+C dont work... How to solve the trouble ?
Octave version 7.1.0

Valeriu Mihailov <valeriumik>
Thu 14 Nov 2019 08:25:01 PM UTC, comment #11: 

John, you are right. Using QKeySequence::Copy as default for the new symbolic constant has probably broken the Ctrl+C behavior.

The interface to the preferences file uses the (human readable) string representation of the key sequences.  For setting a key sequence to an action or a shortcut the string is converted to a QKeySequence.

I will fix the default value for "Copy" and update the related code in QTerminal togehter with extending the comments on the "extra_interrupt" approach.

Torsten Lilge <ttl>
Group Member
Thu 14 Nov 2019 08:55:30 AM UTC, comment #10: 

Works for me now with the latest csets applied.

Pantxo Diribarne <pantxo>
Group Member
Thu 14 Nov 2019 06:31:53 AM UTC, comment #9: 

The default value for sc_main_edit_copy is currently set to QVariant (QKeySequence::Copy), not QVariant ("Ctrl+C").

If I understand correctly, QKeySequence::Copy is an enum value (== 9).  If you store that in a QVariant object and then use toString directly on that QVariant object without first extracting the value as a QKeySequence object, I think you will get QString("9"), not QString("Ctrl+C").

If we want to work with strings, then shouldn't we be setting the default as "Ctrl+C" (or converting QKeySequence::Copy to its string representation)?

If the settings file contains strings like "Ctrl+C", are they converted to QKeySequence objects when they are read or kept internally as QString objects?

Also, looking at the QTerminal sources, has_extra_interrupt is a bit confusing by itself, at least to me.  Maybe there is a better name for that, or some better way to express what is intended?  It seems that has_extra_interrupt (true) means that that the shortcuts for Copy and Interrupt are different.

John W. Eaton <jwe>
Group administrator
Wed 13 Nov 2019 07:54:47 PM UTC, comment #8: 

I do not think that this is a problem, since the key sequences are stored as strings in the settings file (QKeySequence::toString ()) as human-readable strings are a common representation for key sequences (e.g. example Ctrl+P in https://doc.qt.io/qt-5/qkeysequence.html#details)

Torsten Lilge <ttl>
Group Member
Wed 13 Nov 2019 07:14:05 PM UTC, comment #7: 

I guess I'm confused about what the intent of that bit of code is.  To avoid more confusion in the future, can we explain it clearly in the comments there?

Also, it doesn't seem correct to me to convert a key sequence to a string and then back to a key sequence.  That's why I made the change to use the default value for sc_main_edit_copy (QKeySequence::Copy) and extract a QKeySequence from the QVariant object returned by the settings->value function.

If you take an arbitrary QKeySequence value, store it in a QVariant object, extract it as a string, then convert it to a QKeySequence, is it guaranteed that you will recover the original QKeySequence value?  Even if that is true, it seems somewhat strange to me to do that series of conversions.

John W. Eaton <jwe>
Group administrator
Wed 13 Nov 2019 07:01:30 PM UTC, comment #6: 
Torsten Lilge <ttl>
Group Member
Wed 13 Nov 2019 06:29:09 PM UTC, comment #5: 

If I remove all ini files, i.e. the welcome wizard appears, Ctr+C is working.

If octave.ini is removed, octave takes a possibly existing qt-settings file from older version or the much smaller initial ini file, where many prefs are not yet included. In both cases, running octave and especially the settings dialog will change and add several new preferences in the ini file. I guess that,s why you see so many changes.

Torsten Lilge <ttl>
Group Member
Wed 13 Nov 2019 03:22:27 PM UTC, comment #4: 

If you remove the ~/.config/octave/octave-gui.ini file and restart Octave does Ctrl-C work in the command window?

If I do that, Ctrl-C works.  But then if I go to the settings dialog and uncheck the box for "Disable global shortcuts when Command Window has focus", Ctrl-C stops working as the interrupt signal.  After that, selecting the "Disable global shortcuts when Command Window has focus" checkbox doesn't seem to restore the original behavior.

I tried comparing the octave-gui.ini file that was initially created to the one that is saved after I start Octave and uncheck the "Disable global shortcuts..." box but I don't see anything obvious and there are many differences.  The fact that there are so many differences seems strange to me since I only made one change to the settings during my session.

John W. Eaton <jwe>
Group administrator
Wed 13 Nov 2019 02:48:27 PM UTC, comment #3: 

Yes I only observe this in the GUI command window, with hg id 748aea34aecd (from 17 hours ago).

Pantxo Diribarne <pantxo>
Group Member
Wed 13 Nov 2019 02:14:40 PM UTC, comment #2: 

Confirmed.  With dev hg_id 748aea34aecd the GUI I get a popup about ambiguous shortcuts, despite having the Preference > Shortcuts > "Disable global shortcuts ..." enabled.  Same for demos.

In 5.1.0 everything works fine.

Kai Torben Ohlhus <siko1056>
Group Member
Wed 13 Nov 2019 02:12:30 PM UTC, comment #1: 

In the GUI, or also at the command line?

I also noticed the problem, but only in the GUI.  I traced it to this changeset:

  http://hg.savannah.gnu.org/hgweb/octave/rev/315c35e6037c

and I think it was fixed in this one:

  http://hg.savannah.gnu.org/hgweb/octave/rev/959a63d1ede6

and then I reworked the change here:

  http://hg.savannah.gnu.org/hgweb/octave/rev/2c3da07a1aaf

but the fix still worked for me.

John W. Eaton <jwe>
Group administrator
Wed 13 Nov 2019 01:59:14 PM UTC, original submission:  

I noticed recently that Ctrl+C does not interrupt while loops and does not allow to interrupt a demo session anymore.

Pantxo Diribarne <pantxo>
Group Member

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by nrjank (Posted a comment)
  • -email is unavailable- added by valeriumik (Posted a comment)
  • -email is unavailable- added by rik5 (Updated the item)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by siko1056 (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by pantxo (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
    2019-11-14 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2019-11-13 ttl StatusConfirmed Ready For Test
    2019-11-13 siko1056 StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code