Skip to main content
Added more FRs about keyboard shortcuts
Source Link
VLAZ
  • 16.2k
  • 3
  • 37
  • 91

If we tried to make userscript development better, what improvements could we make for you?

Expose the API for creating and modifying keyboard shortcuts. Currently, the only exposed part of the API is the one exported via the revealing module pattern on the StackExchange global object as keyboardShortcuts property with only two public methods: init and destroy.

The abovementioned methods provide only the "all or nothing" API which severely limits the options of userscript developers that would otherwise be willing to provide scripts for customizing shortcuts. In the source, there is a buildShortcuts that makes use of a private Shortcuts constructor instances to add shortcuts.

Even something as simple as exposing these instances (G, inPageNav, and P to be precise) via the function's return value (exported on the keyboardShortcuts nested object) would go a long way for dramatically improving the possibilities for manipulating the shortcuts.

All the above is not an idle concern - there are numerous feature requests that could be handled by the community for the benefit of everyone (including reducing the amount of dev time needed to triage and address those requests). The following is only the tip of the iceberg:

If we tried to make userscript development better, what improvements could we make for you?

Expose the API for creating and modifying keyboard shortcuts. Currently, the only exposed part of the API is the one exported via the revealing module pattern on the StackExchange global object as keyboardShortcuts property with only two public methods: init and destroy.

The abovementioned methods provide only the "all or nothing" API which severely limits the options of userscript developers that would otherwise be willing to provide scripts for customizing shortcuts. In the source, there is a buildShortcuts that makes use of a private Shortcuts constructor instances to add shortcuts.

Even something as simple as exposing these instances (G, inPageNav, and P to be precise) via the function's return value (exported on the keyboardShortcuts nested object) would go a long way for dramatically improving the possibilities for manipulating the shortcuts.

All the above is not an idle concern - there are numerous feature requests that could be handled by the community for the benefit of everyone (including reducing the amount of dev time needed to triage and address those requests). The following is only the tip of the iceberg:

If we tried to make userscript development better, what improvements could we make for you?

Expose the API for creating and modifying keyboard shortcuts. Currently, the only exposed part of the API is the one exported via the revealing module pattern on the StackExchange global object as keyboardShortcuts property with only two public methods: init and destroy.

The abovementioned methods provide only the "all or nothing" API which severely limits the options of userscript developers that would otherwise be willing to provide scripts for customizing shortcuts. In the source, there is a buildShortcuts that makes use of a private Shortcuts constructor instances to add shortcuts.

Even something as simple as exposing these instances (G, inPageNav, and P to be precise) via the function's return value (exported on the keyboardShortcuts nested object) would go a long way for dramatically improving the possibilities for manipulating the shortcuts.

All the above is not an idle concern - there are numerous feature requests that could be handled by the community for the benefit of everyone (including reducing the amount of dev time needed to triage and address those requests). The following is only the tip of the iceberg:

Source Link
0Valt
  • 11.2k
  • 5
  • 24
  • 52

If we tried to make userscript development better, what improvements could we make for you?

Expose the API for creating and modifying keyboard shortcuts. Currently, the only exposed part of the API is the one exported via the revealing module pattern on the StackExchange global object as keyboardShortcuts property with only two public methods: init and destroy.

The abovementioned methods provide only the "all or nothing" API which severely limits the options of userscript developers that would otherwise be willing to provide scripts for customizing shortcuts. In the source, there is a buildShortcuts that makes use of a private Shortcuts constructor instances to add shortcuts.

Even something as simple as exposing these instances (G, inPageNav, and P to be precise) via the function's return value (exported on the keyboardShortcuts nested object) would go a long way for dramatically improving the possibilities for manipulating the shortcuts.

All the above is not an idle concern - there are numerous feature requests that could be handled by the community for the benefit of everyone (including reducing the amount of dev time needed to triage and address those requests). The following is only the tip of the iceberg: