How to best handle Shortcut remapping

[eteran]

Since we aren't using Xdefaults anymore, NG will have an alternative method of allowing users to choose their menu key shortcuts. I think that this provides an opportunity to make things more robust than before.

In the past, it was completely possible to have the shortcuts and what was displayed not in sync with each other.

For example, if you changed nedit*searchMenu.find.accelerator but didn't update nedit*searchMenu.find.acceleratorText then the text would be the default [Shift] Ctrl+F but the actual shortcut would be what the user chose.

One way we can do better is to utilize Qt's ability to create QShortcut objects from strings. So if the user specifies an alternative shortcut for a menu item, the menu item text will reflect that... But there's a catch.

There are about 10 or so menu items that have an "inverse" (or similar) operation available via an extra Shift modifier. There are a few ways to deal with this, but my main idea is this:

NEdit could have a list of these entries and automatically add the shift variant. Meaning that if the user sets Search|Find to Alt+F then it implies Shift+Alt+F will be connected to Find Backwards. The user would never need to explicitly say what the shift variants are. The only problem I see with this is the "what if the shift variant collides with another accelerator?" situation. For example, if they have just by coincidence chosen to make Shift+Alt+F trigger File|Include File to something? Do we just refuse to do it and throw up a message box saying "fix your shortcuts"?

That wouldn't be perfect but seems workable.

And if we do that, what if they explicitly choose a shortcut with Shift in it for a normal operation? Do we just assume that to invert it, they'd want it without shift? That would make sense to me... but I want to maximize intuitiveness.

Thoughts? @tksoh @sjtringali ?

[eteran]

As a follow-up. There are lots of shortcuts that are just kinda hardcoded to specific widgets. Like for example, Ctrl+U means delete-to-start-of-line() in the Text widget. Do we just forbid users from using the few ones that are on that list? Do we go to heroic lengths to make those customizable too?

What about Qt widgets which of course will have their own shortcuts like Ctrl+C for copy in just about every text widget? I don't think those CAN be overridden. Do we allow users to conflict with those and just let Qt do whatever Qt chooses to do with that? Or do we consider them off-limits?

[sjtringali]

I don’t think of the old shortcut remapping as a very user friendly feature. There was no UI and no conflict resolution. It’s programming nedit without recompiling. Thus, I think importing them is a nice-to-have but ultimately low on the list. If there is a way to poke a similar setting via a command line, then even better, that’s functionally equivalent. Removing the ability to have a misleading shortcut is a natural improvement taking advantage of the toolkit. I think Qt has a shortcut remapping dialog box. That would be useful, but post 6.0. I’m not sure what to do about the pairs. I’m inclined to keep them as shift pairs, but it’s hard to tell. Or not... then the question is how to represent it on the menu. Seems like we need to try and see before committing to it.

…

On Jan 3, 2021, at 12:49 AM, Evan Teran ***@***.***> wrote:  Since we aren't using Xdefaults anymore, NG will have an alternative method of allowing users to choose their menu key shortcuts. I think that this provides an opportunity to make things more robust than before. In the past, it was completely possible to have the shortcuts and what was displayed not in sync with each other. For example, if you changed nedit*searchMenu.find.accelerator but didn't update nedit*searchMenu.find.acceleratorText then the text would be the default [Shift] Ctrl+F but the actual shortcut would be what the user chose. One way we can do better is to utilize Qt's ability to create QShortcut objects from strings. So if the user specifies an alternative shortcut for a menu item, the menu item text will reflect that... But there's a catch. There are about 10 or so menu items that have an "inverse" (or similar) operation available via an extra Shift modifier. There are a few ways to deal with this, but my main idea is this: NEdit could have a list of these entries and automatically add the shift variant. Meaning that if the user sets Search|Find to Alt+F then it implies Shift+Alt+F will be connected to Find Backwards. The user would never need to explicitly say what the shift variants are. The only problem I see with this is the "what if the shift variant collides with another accelerator?" situation. For example, if they have just by coincidence chosen to make Shift+Alt+F trigger File|Include File to something? Do we just refuse to do it and throw up a message box saying "fix your shortcuts"? That wouldn't be perfect but seems workable. And if we do that, what if they explicitly choose a shortcut with Shift in it for a normal operation? Do we just assume that to invert it, they'd want it without shift? That would make sense to me... but I want to maximize intuitiveness. Thoughts? @tksoh @sjtringali ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[eteran]

I don't think Qt has a shortcut dialog box, but it wouldn't be hard to make one. In fact, I ported one from Qt Quarterly's Qt3 example to Qt5 in anticipation of this feature 3 years ago ;-)

https://github.com/eteran/qt5-action-editor

I am leaning more and more towards something along the lines of:

NEdit will have a small table of actions that have an inverse operation. Users can specify a shortcut by a string in a .ini/.yaml file. But, for any operations which have an "inverse", the user will get an error if they specify "Shift" in the shortcut. Assuming the shortcut they provided does not a shift, NEdit will automagically connect the shift version as needed based on the shortcut they provided and will display it accordingly on the menu.

So if they try to map "Find" to Ctrl+Shift+H, that's an error.
But they can map "Find" to Ctrl+H which will also imply Ctrl+Shift+H being mapped to "Find Backwards", and of course [Shift] Ctrl+H is what will be displayed in the menu.

Or something like that.

[sjtringali]

Those emacs/terminal-like shortcuts, I’m not sure where they came from. They might be defined by motif out of the box for stock XmText widgets, but memory is hazy. I’m inclined to stick with the platform native shortcuts (See doc for QKeySequence) but if they are otherwise unmapped, I see no harm in leaving them in. Definitely don’t remove ^C etc. that was added because motif out of the box only used CUA style clipboard access. We added Mac/Windows style aliases because the purpose of NEdit was to less LESS unity/emacsy, but we left in the old ones to make it more uniform and compatible where possible. Also note qt MacOS defines a lot of these emacs/terminal style text shortcuts. It’s worth supporting that, and resolving any conflicts humanely. Motif was never a native toolkit on Mac, so discarding the those in favor of the platform ones makes more sense to me, but it could buy it either way. You can augment the stock shortcut menus, it’s not terribly hard.

…

On Jan 3, 2021, at 1:45 AM, Evan Teran ***@***.***> wrote:  As a follow-up. There are lots of shortcuts that are just kinda hardcoded to specific widgets. Like for example, Ctrl+U means delete-to-start-of-line() in the TextA widget. Do we just forbid users from using the few ones that are in that list? What about Qt widgets which of course will have their own shortcuts like Ctrl+C for copy in just about every text widget? I don't think those CAN be overridden. Do we allow users to conflict with those and just let Qt do whatever Qt chooses to do with that? Or do we consider them off-limits? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[eteran]

It's not just about the shortcut menus, stock widgets have tons of keyboard shortcuts seemingly built-in with no obvious way to override them. For example, there's no menu item for Ctrl+U, but at least on Linux, that ALSO is a "delete to start" operation in the stock text boxes.

[eteran]

Also, personally, I am 100% fine with just using the platform-specific shortcuts from things like QKeySequence, I like the defaults :-).

Really this feature is to try to accommodate users who are used to being able to remap these things.