New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GUI For "Remapping Key Assignments and Other Input Gestures" #1532
Comments
Comment 1 by jteh on 2011-05-30 21:19 Good patches are of course welcome. |
Comment 2 by camlorn on 2013-03-31 02:49 |
Comment 3 by jteh on 2013-04-01 22:28 I assume you mean you need to be able to press the key to get the name of the command you want to remap? You don't need the name of the key itself. |
Comment 4 by camlorn on 2013-04-02 02:39 |
Comment 5 by nvdakor on 2013-05-11 09:12 |
Comment 6 by jteh on 2013-08-22 12:55 |
Comment 7 by beqa on 2013-08-27 03:27 i found bug in latest revision activate python console: kb:control+z+nvda |
Comment 8 by nvdakor on 2013-08-29 18:10
|
Comment 9 by jteh (in reply to comment 8) on 2013-08-29 21:59
I'm aware of this. It's very difficult to fix, but obviously needs to be fixed before merge. It's probably the one issue that will very seriously delay this being merged.
The problem is that you can have the same gesture defined in different contexts; e.g. NVDA+shift+b to read battery level but also NVDA+shift+b in a specific app. We could detect a conflict in the same context, but in different contexts, it technically isn't a conflict. Unfortunately, global plugins are all considered different contexts.
UI for this would be difficult without biasing the entire dialog to keyboard gestures. Remember, this is for all input sources (braille displays, etc.), not just keyboard.
Only the commands relevant to the focus can be shown. Other app modules might not even be loaded yet. If a particular app has focus when the dialog is activated, those commands will be included. A keyboard shortcut needs to be added to activate the dialog for this reason. |
Comment 10 by Michael Curran <mick@... on 2013-09-02 06:13
|
Comment 11 by Michael Curran <mick@... on 2013-09-02 06:13
|
Comment 12 by Michael Curran <mick@... on 2013-09-02 06:43
|
Comment 13 by jteh on 2013-09-09 09:29 |
Comment 14 by James Teh <jamie@... on 2013-09-09 09:31
Changes:
|
Comment 15 by James Teh <jamie@... on 2013-09-12 07:04
|
Comment 16 by beqa on 2013-09-14 07:29 maybe this is trivial task but anyway: so, maybe add a prefix with module or make subcategory depending on this module. thanks. |
Comment 17 by jteh (in reply to comment 16) on 2013-09-14 10:11
Can you provide an example?
I think subcategories would be cumbersome and they're also difficult to implement. Depending on the cases you're considering, the problematic commands should perhaps be moved into separate categories. |
Comment 18 by MHameed on 2013-09-15 23:53 For the globalPlugin case, maybe the shortcuts can be categorized by globalPlugin too. This also applicable if a particular language keyboard layout doesn't support the assigned keys. |
Comment 19 by jteh on 2013-09-16 02:32 Any script can choose the category it is assigned to. On individual scripts, you use the category attribute. To set the default category for a class, you use the scriptCategory attribute on the class. This gives the add-on author the choice. Most existing script categories have SCRCAT_* constants in appropriate modules so they can be used by others if desired. |
Comment 21 by James Teh <jamie@... on 2013-10-02 03:30
Changes:
|
Comment 22 by jteh on 2013-10-02 03:31 |
Comment 23 by leonarddr on 2013-10-02 09:51 |
Reported by ateu on 2011-05-30 16:18
Hello
Now nvda allows to do this changes manually, I think you have all the tools and you can easily create a menu iten for this option.
So all the users will enjoy it.
The text was updated successfully, but these errors were encountered: