This has popped up in bug #60182 and bug #61600, and those point back toward bug #60079, and I don’t see any of these fixes reflected in the v7 NEWS.
Is the expected ‘out of the box’ behavior in v7 for the ‘Disable Global Shortcuts…’ preferences option to be on or off?
I just noticed this with 7.0.1. Since GUI ini settings cross versions, it’s hard to tell if mine was enabled by intent or accident.
If expected default behavior has been changed (from ctrl c/v working by default), can that be noted in v7 NEWS before release? If it’s not supposed to be changed, but an inactive ‘on’ setting from v6 may impact behavior after installing v7, maybe there’s some appropriate way to document that?
The default for this option is
true, i.e., the shortcuts are disabled when the terminal widget has focus. This was the default for this preference since it was introduced in 2014.
as long as i can rememer, ctrl-c/v worked in the command window without changing any settings. I just installed v4.4 and 5.1 on windows to test and it worked in both of them. From the bug reports I thought the option not working was only an issue in v6, but was it the case back then as well?
where are gui setting files located in those versions? I think i remember it changing. I can try deleting them to reset to defaults to be sure it’s not something unique on my system.
The defaults are now located in the files
libgui/src/gui-preferences-*.h. In previous version, they were partly stored in
qt-settings-default and were partly hard coded in the related source files.
Have you tested only Ctrl-C/V or other shortcuts, too. It might be, that Ctrl-C/V were considered as special (cases like the switching from one widget to anither) and that this behavior has changed.
I meant more the current settings, i remembered them moving. found the locations in FAQ - Octave
Version 5.2.0 and older: Delete the folder C:\Users\YOUR_USER_NAME\.config\octave
Version 6.1.0 and newer: Delete the folder %APPDATA%\octave, which generally is located at C:\Users\YOUR_USER_NAME\AppData\Roaming\octave
deleting all traces of octave configs in those areas in between, will start checking fresh 4.4, 5.1, 6.4, and 7.0.1 for the setting and ctrl c/v and maybe Ctrl-TAB to switch? should that do something? copy/paste is the only thing i’d noticed.
seems Ctrl-Tab isn’t supposed to work, but Ctrl-N if enabled creates a new document in the editor window and makes it the active window, and does respond to the ‘Disable global shortcuts…’ option.
So, after deleting all settings files, starting with ‘octave-firsttime.vbs’, on windows, using zip packages:
- 4.4.1: ‘Disable global shortcuts…’ starts checked. Ctrl-c/v works in command window. Alt-Tab works to switch outside of octave. Ctrl-N does not. disabling option: Ctrl-N start working, Ctrl-c/v stay working. Alt-Tab stays working.
- 5.1.0: exact same behavior as 4.4.1
- 6.4.0: exact same behavior as 4.4.1
- 7.0.1: "Disable global shortcuts…’ starts checked. Ctrl-C/V does not work in command window. Ctrl-N also doesn’t work. Alt-Tab does. disabling option: Ctrl-C/V now works, Ctrl-N now works. Alt-Tab works.
Unless I’m missing something, at least on Windows Ctrl-C/V not working is a new default behavior (even if unintentional), and should somewhere be documented.
The location of the current settings file has not changed since 6.1.0. You can test Ctrl-Q, which should quit octave if all GUI shortcuts are still active and should do nothing (or the configured readline action) if GUI shortcuts are disabled.
Okay, this seems to prove that Ctrl-C/V were formerly special cases and aren’t anymore in 7.1 for being consistent with the behavior of other shortcuts.
likely correct, and noting that bug #60079 is specific to windows intricacies, I wouldn’t be surprised if that special case also only existed on windows.
probably too verbose, and pending someone making sure the statement is accurate maybe a GUI NEWS item like:
- The preference “Disable global shortcuts when Command Window has focus” is now consistently applied under Windows versions of Octave, and is enabled by default. This option disables keyboard shortcuts like Ctrl-C/V for Copy/Paste, Ctrl-N for creating a new editor document, Ctrl-Q for quitting Octave, etc, to avoid inteference with readline key strokes in the Command Window. Previous versions of Octave inconsistently applied this setting to some shortcuts, including Copy/Paste, which ignored the preference. These shortcuts can be enabled by de-selecting the preference under the Edit/Preferences menu and Shortcuts tab.
Sounds good, except for
Previous versions of Octave inconsistently applied this setting to some shortcuts, including Copy/Paste, which ignored the preference.
Isn’t this a contradiction? The setting was applied to some shortcuts excluding Copy/Paste, since these two were ignoring the setting.
hah, yeah, too much copy/paste rearranging that sentence. I’ll try again
The preference “Disable global shortcuts when Command Window has focus” is now consistently applied under all Operating Systems and is enabled by default. This option disables keyboard shortcuts like Ctrl-C/V for Copy/Paste, Ctrl-N for creating a new editor document, Ctrl-Q for quitting Octave, etc, to avoid interference with readline key strokes in the Command Window. Ctrl-C/V were unaffected by this setting prior to version 7 of Octave for Windows, but are now disabled by default. They can be enabled by de-selecting the preference under the Edit/Preferences menu and Shortcuts tab.
i added a note over on the bug report, but just to make sure the note is accurate, do you have any older versions of octave installed to check whether this previous Ctrl-C/V exception was just on Windows versions?
Thanks for providing the explaining text,
I do not have that old version at hand for testing but i have found the changeset, where copy/paste are handled as other shortcuts, too, when the console has focus and global shortcuts are disabled. This change affected all platforms, therefore the previous Ctrl-C/V exception was on all old version, not only windows.
Would it be better to switch the default for this preference?
I assume that the less experienced user isn’t a “power-user” of readline and might be really confused when shortcuts stops working as soon the console has focus. In addition to that, these users might also have a higher level of reluctance to fiddle around with the preferences.
However, for the experienced user, who attaches value to the readline functionality, it is no problem to change the related preference.
That would be my preference. I’m not sure why the decision was made to have that option enabled by default. I thought it was to preserve the function of ctrl-c. But if copy/paste were exceptions in the past, that doesn’t seem to be the case.
As far as I remember the reason was that the majority of users was used to readline when the GUI was new an that the readline hotkeys should not be shadowed by default.
What about the others? Are there any objections against enabling the GUI shortcuts by default in the console window when these key sequences are then shadowed for readline?
I have changed the default to
false in changeset 60a4fcf2d51b.
ok. that would then seem to eliminate the need for the NEWS statement, unless it’s useful to say something about the default being off, and that it covers all shortcuts now including copy/paste.