bugGNU Octave - Bugs: bug #52361, Ctrl-C/Ctrl-V only works reliably...

 
 

bug #52361: Ctrl-C/Ctrl-V only works reliably if executed as very first action

Submitted by:  Philip Nienhuis <philipnienhuis>
Submitted on:  Tue 07 Nov 2017 07:25:34 PM UTC  
 
Category: GUISeverity: 3 - Normal
Priority: 5 - NormalItem Group: Regression
Status: NoneAssigned to: None
Originator Name: Philip NienhuisOpen/Closed: Open
Release: devOperating System: Microsoft Windows

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Thu 23 Nov 2017 09:11:35 PM UTC, comment #14:

I can confirm the behavior (tested on Win 8.1) with the following observations:

  • Shortcut Ctrl-V does not work in terminal and editor
  • Context-menu for paste in terminal works
  • Context-menu and Menu for paste in editor (and Main-Window) does not work (menu entry disabled)
  • Context-menu for copy in Terminal and editor works
  • Ctrl-X works in editor
Torsten <ttl>
Project Member
Wed 22 Nov 2017 07:20:21 PM UTC, comment #13:

Still not working in hg id a01c210e4287 "delete unused ..."

Could it be related to the OS clipboard being empty when Octave starts?
Because it seems that once I've done a successful copy/paste action, copy/paste in Octave works as it should, also after restarting it w/o copy/paste as first action.

The behavior I described in the bug report is fairly reliable just after starting up / logging into my PC.

FYI I have fairly plain vanilla Windows 7 & 10 installations and o SW that could interfere with the clipboard, AFAIK.

Philip Nienhuis <philipnienhuis>
Project Member
Sun 12 Nov 2017 03:11:50 PM UTC, comment #12:

Philip, thanks for clarifying.

Since the menu entries for copy/cut/paste are grayed out, the shortcuts are probably not the problem but the related actions. I will have a look at this.

Torsten <ttl>
Project Member
Sat 11 Nov 2017 09:34:46 PM UTC, comment #11:
  • Ctrl-C / Ctrl-V as very first command makes copy/cut/paste work reliably in terminal and in editor

Entering any other command may disable Copy/paste key shortcuts.
Pasting into terminal still works using context menu (right-click, select Paste), copying from terminal won't work. In the editor it doesn't work at all and in the editor menu Copy / Cut / Paste are consistently grayed out.
Still present in hg b8cb5a05955e (octve) and f3fb203b6fca (mxe-octave) (up-to-date source trees as of Nov. 11)

Re-configuring seems to make these shortcut key combos work more reliably.

The other issue (qt-settings) may need a bit more investigating - could be interference between qt4 and qt5.
The effect is the other way round - older Octave versions have GUI positions affected adversely, 4.3.0+'s GUI looks good.
I'll enter a bug report for this if required; I want to check a bit better. Maybe wiping qt-settings and starting all over may help.

Philip Nienhuis <philipnienhuis>
Project Member
Sat 11 Nov 2017 05:34:16 PM UTC, comment #10:

Okay, then let me try to summarize the report's issue(s) for tr:

When starting Octave 4.3.0+ (qt5) on windows, Ctrl+C/Ctrl+V does not work in terminal or editor with the following exceptions:

  • Doing Ctrl+C/Ctrl+V as very first action in the terminal makes it work in the terminal
  • Re-configuring the shortcuts in the preferences dialog makes it work in the editor and in the terminal

Second issue (maybe worth another bug report):

When starting Octave 4.3.0+ (qt5) after have been running older versions (<= 4.2.1, qt4/qt5?), the state and positions of the dock widgets are screwed up.

Is this correct and complete?

Torsten <ttl>
Project Member
Sat 11 Nov 2017 04:30:09 PM UTC, comment #9:

A command-line option might help. In the Windows case an adaptation to octave.vbs or octave.bat could also help, maybe that's easier.
Anyway this becomes akin to bug #40444 and bug #36477 :-)

I agree that there's some logic in sharing settings for different program versions. But then it should work flawlessly, in my case it doesn't.

BTW I just made a new cross-build and this bug report''s issue is still there it seems.

Philip Nienhuis <philipnienhuis>
Project Member
Sat 11 Nov 2017 10:12:40 AM UTC, comment #8:

Yes, I am also working with several backups of my settings, so I completely agree that version dependent settings would help here. However, when someone is really working with different octave versions (for whatever reasons), I think the settings should be shared between the versions.

What about the possibility to pass an alternative settings file as command line argument?

Torsten <ttl>
Project Member
Sat 11 Nov 2017 10:03:05 AM UTC, comment #7:

Torsten, I seem to have induced a little thread drift :-)

Yes it is esp. the window position that is problematic across versions - older Octave releases often have the title bar above the upper screen limits so I cannot even move them down.

Still I think (but it's just my opinion) that settings files shouldn't be shared across versions for any piece of SW.
What if I want to test a dev version w/o screwing up settings for a stable release? How to check if installation of a new mxe-octave binary including default qt settings works w/o problems, w/o affecting installed releases?
I suppose having several Octave versions installed side-by-side is mainly a developer situation, but not quite limited to developers.

Currently I have several qt-settings file backups in .config/octave/ , one for each Octave release/version so I can at least restore my personal settings w/o going through several pref tabs. It works but is sub-optimal at best.

OK, next Monday at work I'll see if my "fix" in comment #3 works there as well. If so I'll close this report.

Thanks for you attention.

Philip Nienhuis <philipnienhuis>
Project Member
Sat 11 Nov 2017 09:13:44 AM UTC, comment #6:

Philip, thank you for these detailed information.


If I run an older version of Octave, say 4.03 or 4.2.0, the next time I start 4.3.0+ the GUI pane settings & positions are royally screwed up.

Are these Octave versions all running with the same Qt version? I do not see this effect on ubuntu, but there, the handling of floating dock widgets is different to the windows version. Moreover both tested Octave versions (4.2.1, 4.3.0+) are running with Qt5 on my system. As described in bug #52378, octaves dock widgets are behaving differently in Qt5 when floating.


Those older Octave versions overwrite the qt-settings files upon exit (don't they?), so a newer Octave version started afterwards has to make do with an existing qt-settings made by an older version. So indeed, it then fills in default values for non-default settings it had stored before the older version removed them. Does that scenario make sense to you?

When octave exists, it writes current values of certain preferences back to the settings file but it does not overwrite the complete file. Thus, unknown preferences (from newer Octave versions) are not touched or removed. You can check this by opening the settings file after you have run an older octave version: All preferences for, e.g., the variable editor still exists.

One settings clash I can think of (but maybe I am missing other ones) is the main windows geometry and state which does not contain information of the variable editor when written by older versions. This might also cause the screwing up you are seeing on your system. However, state and geometry of each dock widget are individually stored, too.

Torsten <ttl>
Project Member
Fri 10 Nov 2017 10:30:41 PM UTC, comment #5:

Thank you for enlightening me, Torsten.

All shortcuts looked to be the proper (default) ones before I touched anything in the Shortcuts pref pane.
It must be one of clicking the "Default" button, or "Export" to some file (I couldn't find afterwards, but that's another story).

It makes me think of Jordi's "nasal daemons". But also of some (un)initialization issue.

That preferences are version-independent does not quite match my experience.
If I run an older version of Octave, say 4.03 or 4.2.0, the next time I start 4.3.0+ the GUI pane settings & positions are royally screwed up.
The other way round works fine, that is, older versions work well with qt-settings files from newer versions. And IMO, when you think about it, that makes perfect sense with what I see.
You write: /"The qt-settings file should not be version dependent. If there is a new preference in a new version, a default value is used if the preference is not found in the existing settings file."/
Those older Octave versions overwrite the qt-settings files upon exit (don't they?), so a newer Octave version started afterwards has to make do with an existing qt-settings made by an older version. So indeed, it then fills in default values for non-default settings it had stored before the older version removed them. Does that scenario make sense to you?

For me this is really an issue. I was even thinking of amending the octave.vbs files or m/startup/__finish__.m to copy qt-settings files around.

Philip Nienhuis <philipnienhuis>
Project Member
Fri 10 Nov 2017 06:00:39 PM UTC, comment #4:

Philip, thank you for testing.

  • The .pap files are used for auto completion in the editor. They are stored octave-version depedend since they contain keywords etc.
  • The qt-settings file should not be version dependent. If there is a new preference in a new version, a default value is used if the preference is not found in the existing settings file.

Were the correct shortcuts shown before you have clicked the "Default" button?

"Disable global shortcuts when the terminal has focus" options lets you use the readline shortcuts. Otherwise qt is catching the shortcuts.

Torsten <ttl>
Project Member
Fri 10 Nov 2017 02:57:16 PM UTC, comment #3:

It looks like this issue is caused by the Qt settings stuff in %USERPROFILE%, in particular the .pap-files in %USERPROFILE%\.config\octave\4.3.0+\qsci\
I suppose these files in my profile dir haven't been updated to recent changes in the GUI; or it may even be related to Qt4 => Qt5 upgrades?

In the Shortcut tabs in Preferences pane, I clicked the "Default" button and since then copy/cut/paste to/from the terminal and editor seemed to work fine.

This issue leads me to suggest that the NSIS installer may need a user option to completely overwrite/reset the user preferences for that octave-release.
In addition I think the qt-settings file, which to my knowledge is Octave-release dependent, had better be stored in the %USERPROFILE%\.config\octave\<release> subdir than in %USERPROFILE%\.config\octave\ as it is now.

I'll leave this bug report open until I'm a bit more sure about properly working Ctrl-C/Ctrl-X/Ctrl-V keys.

BTW, what does the option "Disable global shortcuts when the terminal hs focus" option do? - setting or unsetting this option makes no difference, neither before I clicked the Preference|Shortcuts->Default button nor after that action. AFAICS it was always set by default.

Philip Nienhuis <philipnienhuis>
Project Member
Thu 09 Nov 2017 06:59:41 PM UTC, comment #2:

Yes I see nothing strange or missing on the GUI window.
I'll try with other shortcuts.

Philip Nienhuis <philipnienhuis>
Project Member
Thu 09 Nov 2017 06:54:06 PM UTC, comment #1:

Works for me with Qt5 on Ubuntu, thus, no general Qt5 issue. Currently, I have problems to get mxe builds running on my windows vbox, so I can't verify on windows.

I suppose, you are still seeing main and editor menu bars (bug #52250, comment #2)? Does it help to select other shortcuts for copy and paste?

Torsten <ttl>
Project Member
Tue 07 Nov 2017 07:25:34 PM UTC, original submission:

Ctrl-C / Ctrl-V (Copy/Paste) works unreliably in the Octave GUI on Windows. In my memory this has started some weeks, maybe some months ago. Before that time it has worked fine AFAIK, hence "regression".

Immediately after starting the Octave GUI on Windows, I have to select some text in the terminal, enter Ctrl-C and then Ctrl-V, to be able to use copy-paste in the terminal with the Ctrl-C/Ctrl-V key combos.
If I don't and first execute any other command or function, pasting text (e.g., from programs outside Octave) still works in the terminal by right-clicking and selecting "paste"; in the editor copy-paste doesn't work at all anymore.

Perhaps this is related to Qt5? It seems like this started when I switched to Qt5 in my mxe-octave builds.

OS: Windows 7
mxe-octave configured with --enable-windows-64

Philip Nienhuis <philipnienhuis>
Project Member

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by ttl (Posted a comment)
  • -unavailable- added by philipnienhuis (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    No Changes Have Been Made to This Item

    Back to the top


    Powered by Savane 3.1-cleanup1