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

Submitter:  Philip Nienhuis <philipnienhuis>
Submitted:  Tue 07 Nov 2017 07:25:34 PM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  In Progress Assigned to:  None
Originator Name:  Philip Nienhuis Open/Closed:  * Closed
Release:  * dev Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 14 Feb 2020 03:55:15 PM UTC, comment #30: 

That explains it.  Version 4.2.2 is ancient and unsupported and was released before this patch was applied.  Try upgrading to the latest stable version which is 5.2.

Rik <rik5>
Group administrator
Fri 14 Feb 2020 03:32:35 PM UTC, comment #29: 

running Octave 4.2.2 on Windows 10.  Executable was downloaded from the Octave website at gnu.org

Jason Stairs <jasonstairs>
Fri 14 Feb 2020 03:27:55 PM UTC, comment #28: 

@Jason: Which version of Octave are you running, and for Windows, where did you get the executables?

Rik <rik5>
Group administrator
Fri 14 Feb 2020 01:31:16 PM UTC, comment #27: 

Octave with windows...if my first action in the command window is to copy/paste, then it works there, but it doesn't work in the editor at all.  Might there be a fix to this?

Jason Stairs <jasonstairs>
Sun 10 Mar 2019 06:56:55 PM UTC, comment #26: 

Seems to be fixed.  Torsten commented that this is only a workaround, but I'm going to close the report since the patch has been in place for over a year.

Rik <rik5>
Group administrator
Sun 03 Mar 2019 05:39:09 AM UTC, comment #25: 

@Torsten: Do you want to continue to leave this bug open as you mentioned in comment #22 (January, 2018)?

Rik <rik5>
Group administrator
Sun 21 Jan 2018 04:26:31 PM UTC, comment #24: 

Works fine, thanks!

Philip Nienhuis <philipnienhuis>
Group Member
Sat 20 Jan 2018 05:35:51 PM UTC, comment #23: 

Thx, I'll try it out.
It would be wonderful to have a workaround, I'm often hit when I start working with Octave and only then find out that the copy/paste code hadn't initialized.

Philip Nienhuis <philipnienhuis>
Group Member
Sat 20 Jan 2018 12:20:28 PM UTC, comment #22: 

Philip, I have pushed changeset
http://hg.savannah.gnu.org/hgweb/octave/rev/be37df6e1fb4
as a workaround. Instead of the timer, the patch just enables the paste action on windows at start up (so more close to your suggestion in comment #18). While this imposes less load, the paste action remains active even when the clipboard is empty.

Since this is only a workaround and not a real bug fix, I would like to leave this bug report open until the real cause is found.

Torsten Lilge <ttl>
Group Member
Tue 16 Jan 2018 07:23:00 PM UTC, comment #21: 

Thanks for testing, so signaling is really broken.

The paste action in the terminal's context menu is a good "benchmark". The clipboard's state is checked during creation of the context menu, so it does not rely on any signals.

Torsten Lilge <ttl>
Group Member
Tue 16 Jan 2018 06:58:22 PM UTC, comment #20: 

Well :

. Start Octave-4.3.0+
. (Main Menu) Clear clipboard
. Right-click in Terminal pane - Paste = grayed out
However...
. (Editor pane) Edit shows a black (not grayed out) Paste
==> go figure

I never build stable Octave, only dev (bleeding edge). However, building 4.2.1 should be easy, maybe I have time tonight. Could be accommodated easily in currnt mxe, after cleaning up (for which I still may have scripts, from patch #8469).

I don't have a Qt4 mxe build tree anymore, but AFAIR I never saw copy/paste problems with Qt4.

Philip Nienhuis <philipnienhuis>
Group Member
Tue 16 Jan 2018 06:49:12 PM UTC, comment #19: 

When the clipboard is filled during start up, the paste action is enabled. After that, all paste actions are successful, even in cases where the clipboard is empty. It would be interesting if the paste action is grayed out when you clear the clipboard (main menu -> edit). If yes, then the signaling is really working.

If the signaling really does not work, I have thought about a timer as a workaround. Its signal (possibly all 0.2s) then triggers the routine for dis-/enabling the paste action depending on the clipboard's state.

Anyhow, the reason for this issue is still mysterious. Are you also regularly building the stable branch for windows. If yes, also using Qt5? Can you see the issue there, too?

Torsten Lilge <ttl>
Group Member
Tue 16 Jan 2018 06:28:08 PM UTC, comment #18: 

Could a workaround be sending a dummy thing (space, or period, or whatever) to the clipboard before setting up anything else? so that the clipboard is filled?

I've noticed that the second time Octave starts, copy/paste Ctrl-V/Ctrl-C works fine from then on. So I'd figure from then on the QClipboard signal works fine.

Philip Nienhuis <philipnienhuis>
Group Member
Mon 15 Jan 2018 08:55:52 PM UTC, comment #17: 

It seems that on windows, the QClipboard signal, which is emitted when the clipboard contents changes, does not work. At start up, the related slot is explicitly called once for dis- or enabling the paste action depending on the state of the clipboard. That's why pasting is possible when the clipboard contained data at start up.

Unfortunately, I do not know the reason for the broken signaling mechanism (yet).

Torsten Lilge <ttl>
Group Member
Tue 26 Dec 2017 06:59:14 PM UTC, comment #16: 

I've noticed that when paste is disabled in the occtave gui editor, the text I copied from the editor can be pasted to external text editors. As mentioned already, I've noticed that restarting octave lets Ctl-V work again.

Marshall <marsian>
Sun 17 Dec 2017 11:28:53 AM UTC, comment #15: 

Another thing I found out (on Win7) and that I can reliably reproduce:

The first time Octave starts after booting into Windows, Ctrl-V in the GUI terminal doesn't work.
But after the second time, it works fine.

It smells like some skipped initializion somewhere.

Philip Nienhuis <philipnienhuis>
Group Member
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 Lilge <ttl>
Group 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>
Group 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 Lilge <ttl>
Group 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>
Group 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 Lilge <ttl>
Group 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>
Group 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 Lilge <ttl>
Group 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>
Group 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 Lilge <ttl>
Group 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>
Group 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 Lilge <ttl>
Group 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>
Group 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>
Group 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 Lilge <ttl>
Group 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>
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 jasonstairs (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by marsian (Posted a comment)
  • -email is unavailable- added by marsian
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by philipnienhuis (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 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-03-10 rik5 Open/ClosedOpen Closed
    2018-01-20 ttl StatusNone In Progress
    2017-12-26 marsian Carbon-Copy- Added marsian

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code