bugGNU Octave - Bugs: bug #49571, Command-c and command-v aren't...

 
 

bug #49571: Command-c and command-v aren't default cut/paste in editor (and command-v doesn't work even when changed in preferences)

Submitter:  John Swensen <jpswensen>
Submitted:  Wed 09 Nov 2016 06:14:59 PM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Need Info Assigned to:  None
Originator Name:  jpswensen Open/Closed:  * Closed
Release:  * dev Operating System:  * Mac OS
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 10 Mar 2019 09:52:29 PM UTC, comment #28: 

@Rik

Sorry for not replying earlier. I hadn't followed up since I switched to Homebrew and Qt5.

cmd-c and cmd-v are mapped correctly using the default branch.

Ben Abbott <bpabbott>
Group Member
Sun 10 Mar 2019 06:43:31 PM UTC, comment #27: 

No response, asumming this has been fixed in the latest release.  Closing report.

Rik <rik5>
Group administrator
Sun 03 Mar 2019 07:01:13 AM UTC, comment #26: 

The last comment on this bug report was over a year ago.  Does anything more need to be done?  Has the new 5.1.0 release fixed things?

Rik <rik5>
Group administrator
Fri 19 Jan 2018 04:12:24 PM UTC, comment #25: 

That is correct: the current version of qt4 under MacPorts is 4.8.7.

Marius Schamschula <mschamschula>
Fri 19 Jan 2018 04:05:30 PM UTC, comment #24: 

But even with QT4 on Macpirts, it is 4.8 or above, right? The WT changes to keyboard shortcut handling has been the same since 4.8.

John Swensen <jpswensen>
Fri 19 Jan 2018 03:52:56 PM UTC, comment #23: 

MacPorts uses Qt5 by default, but if a user upgrades an older octave install, it will build against Qt4 if the previous version was built that way.

Over the last several months, I moved my machines over to the new default variant.

Marius Schamschula <mschamschula>
Fri 19 Jan 2018 03:44:07 PM UTC, comment #22: 

@John, Fink has a Qt5 package, but I was not able to get it to work. I suspect the Fink guys will be able to ... assuming there is interest on their side. fwiw, Homebrew looks to be gaining in popularity over Fink and MacPorts.

For convenience, I'm ok with the assumption that Qt>4.8 on macOS, but would prefer to avoid decisions that prohibit a follow up change that adds support for Qt 4.8.

Ben Abbott <bpabbott>
Group Member
Fri 19 Jan 2018 07:32:16 AM UTC, comment #21: 

I am going to pick this one up again, but would ask in the last 4 months whether we can now assume that we are using QT5 for all MacOS builds? If that is the case, it makes the solution a lot more simple.

@bpabbott You made it sound a while back that you were still building with QT4 with Fink (not sure if <4.7), but you recently gave me scripts for Homebrew with QT5. Fink doesn't even look like it has a default package for >Octave 3.8. Both Fink and Macports have version 4.8+ at their qt4 version, so I think we are safe to assume that every MacOS package manager is shipping >4.8.

So, unless anyone has objections, I am going to proceed by modifying any MacOS-specific sections under the assumption that Octave is being built with QT >4.8. Does anyone have any objections to this assumption?

John Swensen <jpswensen>
Thu 21 Sep 2017 10:18:23 PM UTC, comment #20: 

Sorry, that should be QT_VERSION < 0x050000, not <=.

John W. Eaton <jwe>
Group administrator
Thu 21 Sep 2017 10:17:28 PM UTC, comment #19: 

Could this patch be just the one line change


diff --git a/libgui/src/m-editor/octave-qscintilla.cc b/libgui/src/m-editor/octave-qscintilla.cc
--- a/libgui/src/m-editor/octave-qscintilla.cc
+++ b/libgui/src/m-editor/octave-qscintilla.cc
@@ -156,7 +156,7 @@ octave_qscintilla::octave_qscintilla (QW
     }
 #endif

-#if defined (Q_OS_MAC)
+#if (QT_VERSION <= 0x050000) && defined (Q_OS_MAC)
   // Octave interprets Cmd key as Meta whereas Qscintilla interprets it
   // as Ctrl. We thus invert Meta/Ctrl in Qscintilla's shortcuts list.
   QList< QsciCommand * > cmd_list_mac = cmd_set->commands ();


?  John Swensen's patch removed this code unconditionally.  I'm just proposing that it only be used on Mac systems with Qt versions less than 5.0.  Comments?

John W. Eaton <jwe>
Group administrator
Thu 31 Aug 2017 10:41:43 PM UTC, comment #18: 

@John: This bug is report is still dragging on.  Can you commit your patch?

Rik <rik5>
Group administrator
Thu 01 Jun 2017 07:19:20 PM UTC, comment #17: 

@John: Can you commit your patch for shortcuts?  Or is there still something to tweak for Qt4 and Qt5 support?

Rik <rik5>
Group administrator
Mon 10 Apr 2017 04:39:58 PM UTC, comment #16: 

@John: Are you ready co commit something now?  It looks like the patch should support both Qt4 and Qt5 for the time being.

Rik <rik5>
Group administrator
Thu 10 Nov 2016 09:18:08 PM UTC, comment #15: 

I guess this means that I will make the patch to detect QT4 vs QT5 and  keep things the way they are for QT4 and rely on the OS-independent features for QT5.

Thanks for checking for me.

John Swensen <jpswensen>
Thu 10 Nov 2016 09:16:04 PM UTC, comment #14: 

I'm using QT4 with Fink. QT5 is available. I haven't bothered to attempt to make all the changes needed to get it working.

Ben Abbott <bpabbott>
Group Member
Thu 10 Nov 2016 07:04:52 PM UTC, comment #13: 

I am only looking at whether the 3 major OSX build systems have settled on QT5. The only parts that expect QT5 behavior would be isolated to OSX environments.

Even as it stands now, if Fink or Macports is still on QT4, I will make my OSX-specific patch to try and workaround both.

John Swensen <jpswensen>
Thu 10 Nov 2016 06:57:25 PM UTC, comment #12: 

Please let's not require Qt 5 (from a source distribution, platform-agnostic point of view) for a little while as long as Qt 4 still works for most users. If we start getting bug reports about things not compiling, or requiring immense conditional compilation workarounds for Qt 4, then we can drop it. Qt 4 is still the default Qt version on Debian, maybe for another year or so. I am building and using Octave with Qt 5, but most repository packages, including Octave, are still built against Qt 4.

If you want to make changes that drop things that were needed on macOS with Qt 4, and effectively no one is using Qt 4 on macOS now, that's fine with me.

Mike Miller <mtmiller>
Group Member
Thu 10 Nov 2016 06:46:12 PM UTC, comment #11: 

Ben Abbott and Marius Schamschula, can you comment on which version of QT is used for Fink and Macports? If both of those use QT5, I think we can dispense with supporting the weird modifier behavior of QT4 <4.7 and it makes this patch a lot easier.

John Swensen <jpswensen>
Thu 10 Nov 2016 06:34:38 PM UTC, comment #10: 

You can add people to the CC list for the bug and they will get subsequent posts.  I usually add people to the CC list as well as adding a comment asking for review so they get both things at once.  Ben Abbott (bpabbott) has been a long time Mac user on Octave.  There are others I'm sure.

Rik <rik5>
Group administrator
Thu 10 Nov 2016 06:25:48 PM UTC, comment #9: 

I was under the impression that QT5 was already required for OSX. If that is not the case, then my proposal is probably problematic. We would need to make my changes to the Q_OS_MAC sections be dependent on which QT version is being used. As far as I could tell from the QT documentation, any QT version >=4.7 should have the same platform-independent modifier key behavior.

Could someone who uses Fink or Macport (I use homebrew) comment on which version of QT is used for building Octave? Is there a way to tag people in these bug reports so that they get and email knowing they were mentioned?

John Swensen <jpswensen>
Thu 10 Nov 2016 06:13:47 PM UTC, comment #8: 

That sounds fine.  Will your patch work with Qt4 or Qt5 on the stable branch?

And in the future should we move to require QT5, i.e., modern libraries, for the development branch?

Rik <rik5>
Group administrator
Thu 10 Nov 2016 05:48:36 PM UTC, comment #7: 

Sorry to comment so much, but I just did a quick test of removing all the Q_OS_MAC specific sections of the UI code that related to keyboard shortcuts and everything work exactly as I expect it to, with one exception. The exception is that in the terminal window, now command-c is what is necessary to interrupt the execution of a script. This kindof makes sense because QT5 tries to make command-c do what control-c would be on any other platform.

This seems to indicate to me that there have been improvements to both QScintilla and QT5 that allows software to be written once and have the shortcut behavior be OS-consistent with other apps, but without having to change anything.

So, my proposed patch would include the following:
1) remove all the existing Q_OS_MAC related shortcut code to allow QT5 and QScintilla to do the OS-specific mapping on its own.
2) Add new Q_OS_MAC related shortcut code to the command window to make ctrl-c be interrupt and command-c be copy.
3) Add new Q_OS_MAC related code to use the right language in the preferences pane for command, option, and control modifiers.

Thoughts?

John Swensen <jpswensen>
Thu 10 Nov 2016 05:14:17 PM UTC, comment #6: 

Let me a more thorough investigation and patch first. Even in the preferences pane, I would like it to show "command-c" instead of "control-c" and "option-c" instead of "meta-c" to be consistent with OSX UI practices.

I also want to make sure that all the shortcuts are working as expected and that changing them in the preferences pane actually takes effect. I just noticed that with my patch, if I actually go set the copy shortcut to "command-c" in the preferences pane that "command-c" stops working, but "control-c" still works.

So, there is still some investigation and patch polishing to do before it should be applied.

John Swensen <jpswensen>
Thu 10 Nov 2016 04:51:04 PM UTC, comment #5: 

In terms of quality of life, this seems like a big issue for Mac users.  Should the change, whatever it is, be made on stable?

Rik <rik5>
Group administrator
Thu 10 Nov 2016 04:10:19 PM UTC, comment #4: 

Homebrew now has Qscintilla 2.9.3

As of right now, when I remove that section of code that swaps everything works as expected:
1) command-c and control-c act as a copy in the editor and other text boxes
2) control-c acts as control-c in the terminal window, command-c acts as a copy
3) command-v and control-c act as a paste in all windows
4) command-z and control-z act as a backup
5) ctrl-a goes to the start of a line, ctrl-e goes to the end of the line
6) command-a DOES NOT select the entire text in the editor or terminal. It does select all text in all other panels.

>>>> Snippet from the QT5 documentation

Note: On OS X, references to "Ctrl", Qt::CTRL, Qt::Control and Qt::ControlModifier correspond to the Command keys on the Macintosh keyboard, and references to "Meta", Qt::META, Qt::Meta and Qt::MetaModifier correspond to the Control keys. Developers on OS X can use the same shortcut descriptions across all platforms, and their applications will automatically work as expected on OS X.

>>>> End snippet


It seems that we may be able to cut out this code because it was an artifact of QT4 and older versions of QScintilla

John Swensen <jpswensen>
Thu 10 Nov 2016 10:29:04 AM UTC, comment #3: 

Also, what is your version of QScintilla? IIRC I used 2.7 at the time.

Pantxo Diribarne <pantxo>
Group Member
Thu 10 Nov 2016 09:33:14 AM UTC, comment #2: 

Hi,

Here is what I recall: the default in Qt4 was to swap CMD and CTRL keys so that typing CMD+C is equivalent to CTRL+C on other platforms. We had to change this default behavior as it prevented Mac users from working with standard readline shortcuts (CTRL+C/A/E/U...) in the command window (http://hg.savannah.gnu.org/hgweb/octave/rev/58f1178f49ef cancels the swap).

The problem with the above change is that QScintilla (used to?) assume the CTRL is CMD on Mac and the second cset you mention (http://hg.savannah.gnu.org/hgweb/octave/rev/c6b89c4a9e63) tried to address  this by manually swapping default QScintilla shortcuts.

Do CTRL+A and CTRL+E in the editor move the cursor to the beginning and end of line respectively? Sorry I have no Mac anymore for testing.
 


Pantxo Diribarne <pantxo>
Group Member
Wed 09 Nov 2016 10:03:55 PM UTC, comment #1: 

I'm not quite sure if this fix was leftover from a time when Qscintilla worked differently, but as far as I can tell, QScintilla now follows the QT4.7+ standard of Command (see the QKeySequence section at http://doc.qt.io/qt-5/qkeysequence.html)

So, as far as I can tell, simply deleting that whole OSX-specific section in the octave_qscintilla constructor seems to solve all my problems:
1) command-c acts as a copy
2) command-v acts as a paste
3) command-z acts as a backup
4) CTRL-C interrupts an executing script (and crashes the GUI if done from the prompt, but that is an already existing bug report).

I have attached a patch, but maybe other OSX users want to confirm.

(file #38921)

John Swensen <jpswensen>
Wed 09 Nov 2016 06:14:59 PM UTC, original submission:  

I saw the Bug #41217 from over two years ago tried to address the problem of default shortcuts on OSX, but it seems that even if that was working then it isn't working now.

It seems that everywhere else in the GUI that command-c and command-v are the the defaults for copy and paste (e.g. in the terminal window, in the filter boxes, and in the directory textedit). However, in the editor command-v does not work to paste. Command-c does work. Instead, command-v moves the cursor to the last line of the current file.

If I go and try to change the current global shortcuts in the Preferences pane, to the command-v instead of meta-v, then even the command-v stops working in the other parts of the GUI.

John Swensen <jpswensen>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #38921:  OSX_copy_paste_fix.diff added by jpswensen (1KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by mschamschula (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by bpabbott (Posted a comment)
  • -email is unavailable- added by jpswensen (Adding to make comments on QT version for Macports and Fink)
  • -email is unavailable- added by jpswensen (Adding to make comments on QT version for Macports and Fink)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by jpswensen (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 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-03-10 rik5 StatusPatch Submitted Need Info
        Open/ClosedOpen Closed
    2019-02-26 mtmiller Carbon-CopyRemoved 80942 -
    2018-01-19 rik5 Carbon-CopyRemoved 72865 -
    2017-09-15 rik5 StatusNone Patch Submitted
    2016-11-10 jpswensen Carbon-Copy- Added -email is unavailable-
        Carbon-Copy- Added -email is unavailable-
    2016-11-09 jpswensen Attached File- Added OSX_copy_paste_fix.diff, #38921

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code