Thu 21 Sep 2017 10:18:23 PM UTC, comment #20:
Sorry, that should be QT_VERSION < 0x050000, not <=.
|
Thu 21 Sep 2017 10:17:28 PM UTC, comment #19:
Could this patch be just the one line change
? 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?
|
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?
|
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?
|
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.
|
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.
|
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.
|
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.
|
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.
|
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.
|
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.
|
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?
|
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?
|
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?
|
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.
|
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?
|
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
|
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.
|
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.
|
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)
|
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.
|