nvaccess
TerminalModules
Proposal for terminalModules, Modules for terminal apps.
Abstract:
Since terminal apps have no way of being detected, traditional appModules can't be written. For example, assume I enter vim to edit a file on my server. Since vim has strange commands, such as h j k l w ce % i a ... I'd love to be able to use these. However, I need to teach NVDA about it. Further complicating things, there's no way for NVDA to detect that vim is running since all it can see is a plain boring grid of chars and the app doesn't change, since I'm in an ssh session. This proposal lines the design for a terminal customization system, and a GUI for enabling terminal modes for the current session.
Development
A class called TerminalModule, and its associated terminalModule addon type should be created. A terminalModuleHandler might need added.
A terminalModule should receive typed char notifications via event_typedChar, caret events, etc. and I'm probably missing at least one use case here for other events to receive.
There's probably no need for chooseNVDAObjectOverlayClasses because terminals lack structure, hence a need for this. terminalModules should allow scripts on any terminal.
Multiple terminal modules should be allowed to be enabled at once, say vim and screen. For example, a screen module could be created that reads the title bar if control+a followed by n is pressed. However, one of the users screens is in vim, thus vim module is enabled from the GUI as well.
When a terminal gains focus, (Role of terminal, or behaviors.Terminal in the list of classes), we send events and scripts ..., if a terminal isn't in focus, we don't.
GUI component
Since there's no way whatsoever for a terminal app to say invoke me when this happens, we should present a GUI in response to a keypress. I propose NVDA+space I.E. change modes. I'm thinking of something similar to the addons manager, Ideally a checkable list of all modes would be best. Each mode the user wants could be toggled. Alternatively, nvda+space could just cycle through each mode (No GUI at all), and a GUI from tools could be available to add or remove a mode from the ring of modes in the nvda+space order.
I'm assuming you refer to both the command prompt and the run dialogue if running a command file, say a batch file from there or from a shortcut. also the new versions of command prompt that are called other things but really just arre like dos prompts with extras. I use batch files a lot in windows to do stuff as I do not much care what the screen does as long as things happen I want to happen. Brian
[email protected] Sent via blueyonder. Please address personal email to:- [email protected], putting 'Brian Gaff' in the display name field. ----- Original Message ----- From: "derekriemer" [email protected] To: "nvaccess/nvda" [email protected] Cc: "Subscribed" [email protected] Sent: Friday, February 03, 2017 1:30 PM Subject: [nvaccess/nvda] TerminalModules (#6835)
Proposal for terminalModules, Modules for terminal apps.
Abstract:
Since terminal apps have no way of being detected, traditional appModules can't be written. For example, assume I enter vim to edit a file on my server. Since vim has strange commands, such as h j k l w ce % i a ... I'd love to be able to use these. However, I need to teach NVDA about it. Further complicating things, there's no way for NVDA to detect that vim is running since all it can see is a plain boring grid of chars and the app doesn't change, since I'm in an ssh session. This proposal lines the design for a terminal customization system, and a GUI for enabling terminal modes for the current session.
Development
A class called TerminalModule, and its associated terminalModule addon type should be created. A terminalModuleHandler might need added.
A terminalModule should receive typed char notifications via event_typedChar, caret events, etc. and I'm probably missing at least one use case here for other events to receive.
There's probably no need for chooseNVDAObjectOverlayClasses because terminals lack structure, hence a need for this. terminalModules should allow scripts on any terminal.
Multiple terminal modules should be allowed to be enabled at once, say vim and screen. For example, a screen module could be created that reads the title bar if control+a followed by n is pressed. However, one of the users screens is in vim, thus vim module is enabled from the GUI as well.
When a terminal gains focus, (Role of terminal, or behaviors.Terminal in the list of classes), we send events and scripts ..., if a terminal isn't in focus, we don't.
GUI component
Since there's no way whatsoever for a terminal app to say invoke me when this happens, we should present a GUI in response to a keypress. I propose NVDA+space I.E. change modes. I'm thinking of something similar to the addons manager, Ideally a checkable list of all modes would be best. Each mode the user wants could be toggled. Alternatively, nvda+space could just cycle through each mode (No GUI at all), and a GUI from tools could be available to add or remove a mode from the ring of modes in the nvda+space order.
-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/nvaccess/nvda/issues/6835
No. Just anything that's a terminal. The run dialog isn't a terminal.
On Fri, Feb 3, 2017 at 9:06 AM, Brian1Gaff [email protected] wrote:
I'm assuming you refer to both the command prompt and the run dialogue if running a command file, say a batch file from there or from a shortcut. also the new versions of command prompt that are called other things but really just arre like dos prompts with extras. I use batch files a lot in windows to do stuff as I do not much care what the screen does as long as things happen I want to happen. Brian
[email protected] Sent via blueyonder. Please address personal email to:- [email protected], putting 'Brian Gaff' in the display name field. ----- Original Message ----- From: "derekriemer" [email protected] To: "nvaccess/nvda" [email protected] Cc: "Subscribed" [email protected] Sent: Friday, February 03, 2017 1:30 PM Subject: [nvaccess/nvda] TerminalModules (#6835)
Proposal for terminalModules, Modules for terminal apps.
Abstract:
Since terminal apps have no way of being detected, traditional appModules can't be written. For example, assume I enter vim to edit a file on my server. Since vim has strange commands, such as h j k l w ce % i a ... I'd love to be able to use these. However, I need to teach NVDA about it. Further complicating things, there's no way for NVDA to detect that vim is running since all it can see is a plain boring grid of chars and the app doesn't change, since I'm in an ssh session. This proposal lines the design for a terminal customization system, and a GUI for enabling terminal modes for the current session.
Development
A class called TerminalModule, and its associated terminalModule addon type should be created. A terminalModuleHandler might need added.
A terminalModule should receive typed char notifications via event_typedChar, caret events, etc. and I'm probably missing at least one use case here for other events to receive.
There's probably no need for chooseNVDAObjectOverlayClasses because terminals lack structure, hence a need for this. terminalModules should allow scripts on any terminal.
Multiple terminal modules should be allowed to be enabled at once, say vim and screen. For example, a screen module could be created that reads the title bar if control+a followed by n is pressed. However, one of the users screens is in vim, thus vim module is enabled from the GUI as well.
When a terminal gains focus, (Role of terminal, or behaviors.Terminal in the list of classes), we send events and scripts ..., if a terminal isn't in focus, we don't.
GUI component
Since there's no way whatsoever for a terminal app to say invoke me when this happens, we should present a GUI in response to a keypress. I propose NVDA+space I.E. change modes. I'm thinking of something similar to the addons manager, Ideally a checkable list of all modes would be best. Each mode the user wants could be toggled. Alternatively, nvda+space could just cycle through each mode (No GUI at all), and a GUI from tools could be available to add or remove a mode from the ring of modes in the nvda+space order.
-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/nvaccess/nvda/issues/6835
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/6835#issuecomment-277287664, or mute the thread https://github.com/notifications/unsubscribe-auth/AFGivWMfobywt1UM1APXhZK_ptHjchXMks5rY1B2gaJpZM4L2Uz3 .
--
Derek Riemer: Improving the world one byte at a time!
- University of Colorado Boulder Department of computer science, 4th year undergraduate student.
- Accessibility enthusiast.
- Proud user of the NVDA screen reader.
- Open source enthusiast.
- Skier.
Personal website http://derekriemer.com
No updates from users who could reproduce this since many years upon request, closing as abandoned. if you are still having this issue, please comment and we can reopen.
@Adriani90:
- Before closing an issue for lack of update, I'd recommend that you tag the person from which you expect an update (here @derekriemer)
- Not sure that feature requests need to be closed due to lack of update, especially with #18379.
I prefer reopen the issue and ask @seanbudd. Thanks.
@CyrilleB79 sorry I didn't tag Derek since he is not very active on Github in this repository anymore. On the other hand, the last two comments do not really contribute to bring forward this discussion.
So my question again which I already raised some years ago: does UIA in consoles have any positive effect on this request? If people have interest in this feature, it would be nice to have some updates instead of noisy comments.
I don't think UIA will have any effect on this. This issue is about how to organize character reading, which may require a heuristic algorithm. Unless UIA can report the program currently running on the terminal.