Re: Accessible tools
On 2015-02-22 20:29, Jacob Kruger wrote: jaws, doesn't always cooperate perfectly with command line/console interface I've heard that on multiple occasions. Since I mostly work with Linux, the only terminal-with-screen-reader hints I've heard involve using TeraTerm as the SSH client with NVDA on Windows. Sorry I can't be of much more assistance there, since I haven't really used Windows for years. this page seems to offer enough detail relating to PDB, to start off with anyway: https://docs.python.org/3/library/pdb.html My generally process is as follows: 1) add the following line some place before where I want to debug: import pdb; pdb.set_trace() 2) run my program 3) when it hits that line of code, it drops you to the debugging prompt 4) poke around, using print followed by the thing(s) I want to inspect such as print dir(something) print my_var.some_field 5) step to the next line of code with n or step into a function/method call with s or exit/return from the current function/method with r. I'll also use l (ell) to list some context around the current line so I can tell where I am in the source code. This is particularly helpful as I can use the corresponding line-number(s) to jump to the same line in my editor if I spot the offending line of code, then edit it. very rarely, I'll actually set additional breakpoints (optionally making them conditional) but I *always* have to look up the syntax for that. Hopefully that gets you at least to the point where debugging isn't some laborious task. Best wishes, -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Accessible tools
- Original Message - From: Tim Chase python.l...@tim.thechases.com Subject: Re: Accessible tools While my experience has shown most of your items to be true, I'd contend that • Do not, have access to debugging tools. is mistaken or at least misinformed. For Python, I use the pdb module all the time, and it's command-line driven. Combined with a multi-terminal (whether multiple windows, virtual consoles, or a tmux/screen session), I can easily bounce back and forth between a pdb debugging session and the source code to make edits. Just to check, I fired up the yasr terminal screen-reader, launched tmux (using my quiet config, since it updates information on the screen like the time on a regular basis, making it chatty), and stepped through some Python code, checked variables, and walked up/down the call-stack. I know most other languages have similar functionality such as gdb for C code. Will check out PDB a bit more, but, honestly, my windows screenreader that use most of the time, jaws, doesn't always cooperate perfectly with command line/console interface - can be worked around, but, not all that easily at times - but, this page seems to offer enough detail relating to PDB, to start off with anyway: https://docs.python.org/3/library/pdb.html Jacob Kruger Blind Biker Skype: BlindZA Roger Wilco wants to welcome you...to the space janitor's closet... -- https://mail.python.org/mailman/listinfo/python-list
Re: Accessible tools
Eric, Although I would most likely enjoy the former option I feel the latter would be most appropriate for contacting you. Thanks for getting back to me and explaining some of this. I will contact you off list for sure so as not to fill up the lists mailboxes with this topic. I will say that Jacob is absolutely correct in the fact that those of us who rely on screen readers to interact with our computers have a few things we do, and tend to not do. • Do type very efficiently • Do listen to our speech output very fast • Do interact with the text line, word, and character at a time. • Do not, use a mouse • Do not, enjoy reading through several lines of code at a time to locate a specific issue, method, or block of code. • Do not, have access to debugging tools. This is just a few things we do and do not do typically, but the point is that even though some things are similar there are some things that are quite different. Here is an example. I would not use a voice driven editor because I tend to build out a layout of code before I begin filling in methods, functions, and constructors. For me to do this with voice would require the use of a mouse to place the cursor where I want each line of code to be placed, and since I do not have access to the mouse in that way this would not work well. On the other hand if the program could interpret what you are speaking to build out method signatures and individual lines of code accurately, then there is a good chance that same system could provide a great interface for a screen reader. Thank you again for the response and be expecting an email from me shortly sir. On Feb 20, 2015, at 11:39 AM, Jacob Kruger ja...@blindza.co.za wrote: Eric, issue is that with screenreaders, we're generally way more into navigating code and interface character by character/by keyboard, so , yes, keeping interface relatively simple is a good thing, but, we also would prefer to primarily keep all interface elements to make use of standard UI controls, and make sure tab index/order is suitable/relevant at times, etc. etc. As in, I think we'd primarily want to avoid having to use a mouse at all if possible, but anyway. Stay well Jacob Kruger Blind Biker Skype: BlindZA Roger Wilco wants to welcome you...to the space janitor's closet... - Original Message - From: Eric S. Johansson e...@harvee.org To: python-list@python.org Sent: Friday, February 20, 2015 7:22 PM Subject: Re: Accessible tools On 2/19/2015 10:33 AM, Bryan Duarte wrote: Thank you jwi, and Jacob, I took a look at that posting and it seems pretty unique. I am not much interested in the speech driven development, but I am very interested in developing an accessible IDE. Well you should be because it looks like an aural interface (uses speech instead of keyboards) uses the same kinds of data to present to either a text to speech or speech recognition driven environment. A professor and I have been throwing around the idea of developing a completely text based IDE. There are a lot of reasons this could be beneficial to a blind developer and maybe even some sighted developers who are comfortable in the terminal. The idea would be really just to provide a way of easily navigating blocks of code using some kind of tabular formatting, and being able to collapse blocks of code and hearing from a high level information about the code within. All tools and features would obviously be spoken or output in some kind of audio manor. I've been working with another professor working on some of these issues as well. His focus has been mostly blind young adults in India. come up with some pretty cool concepts that looks very usable. The challenge now is to make them work and, quite frankly monetize the effort to pay for the development. Again, this shows the similarities in functionality used by both speech recognition and text-to-speech. All I care about is text and what I can say. We're now working with constructs such as with-open, argument by number, plaintext symbol names (with bidirectional transform to and from code form), guided construct generation for things like classes, methods, comprehensions etc. All of these things would be useful to handed programmers as well as a way of accelerating co-creation and editing. Unfortunately, like with disabled people stove piping text-to-speech versus speech recognition, handed developers stovepipe keyboard interfaces and don't really think about what they are trying to do, only how they are doing it. Yes yes, it's a broadbrush that you can probably slap me with. :-) Oh and before I forget does anyone know how to contact Eric who was developing that accessible speech driven IDE? Thanks Well, you could try looking in a mirror and speaking my name three times at midnight But you would get better results if you used my non-mailing list email address. e
Re: Accessible tools
On 2015-02-21 10:21, Bryan Duarte wrote: those of us who rely on screen readers to interact with our computers have a few things we do, and tend to not do. [snip] While my experience has shown most of your items to be true, I'd contend that • Do not, have access to debugging tools. is mistaken or at least misinformed. For Python, I use the pdb module all the time, and it's command-line driven. Combined with a multi-terminal (whether multiple windows, virtual consoles, or a tmux/screen session), I can easily bounce back and forth between a pdb debugging session and the source code to make edits. Just to check, I fired up the yasr terminal screen-reader, launched tmux (using my quiet config, since it updates information on the screen like the time on a regular basis, making it chatty), and stepped through some Python code, checked variables, and walked up/down the call-stack. I know most other languages have similar functionality such as gdb for C code. -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Accessible tools
Tim, I am also on the blind linux list. I do not often post there as I predominately use a Mac and the Unix terminal but I am using Linux Kali on the side for some side tinkering and learning. I would use Linux a lot more if the screen reader was not so robotic... Would you be willing to be included in some accessibility QA or to bounce some ideas off of? On Feb 19, 2015, at 11:43 AM, Tim Chase python.l...@tim.thechases.com wrote: While not blind, I have an interest in accessibility and answer a number of questions on the Blinux (Blind Linux Users) mailing list. On 2015-02-19 08:33, Bryan Duarte wrote: A professor and I have been throwing around the idea of developing a completely text based IDE. There are a lot of reasons this could be beneficial to a blind developer and maybe even some sighted developers who are comfortable in the terminal. The idea would be really just to provide a way of easily navigating blocks of code using some kind of tabular formatting, and being able to collapse blocks of code and hearing from a high level information about the code within. All tools and features would obviously be spoken or output in some kind of audio manor. It would seem that the traditional Unix-as-IDE[1] would serve you well here. This is my method of choice, and it allows me to pick my components and combine them. I usually use tmux, though GNU screen would do too. Within that, I usually have the following: - vim to edit my code. Though swap in your favorite, whether emacs/emacspeak, ed/edbrowse, joe, nano, or whatever. I know that at least Vim and emacs support folding away blocks of code (what you describe as collapsing) which I usually prefix with a comment that would give you a description of the block - a command-line (I use bash, some prefer zsh or tcsh or whatever) for things like version-control, running my code, and file management (move/copy/delete/rename/link/etc) - a Python command-line REPL that allows me to do quick tests on a line of code as well as well as make extensive use of Python's built-in dir() and help() commands which are invaluable. - when doing web-development (Django in my case), I'll often have the dev-server running in one pane, and a console browser like lynx/links/links2/elinks/w3m in another pane so that I can put my code through its paces Another benefit of this is that I can run this on my development machine, but then SSH into the machine from anywhere, reattach to the tmux/screen session, and have the same configuration right as I left it. The entire tmux/screen session can be run within an accessible terminal window (I know that some are more accessible than others), within a terminal screen-reader session (like yasr, screader, or emacspeak), or even remoted into via an accessible SSH program on your platform of choice. -tkc [1] http://blog.sanctum.geek.nz/series/unix-as-ide/ -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Accessible tools
On 2/19/2015 10:33 AM, Bryan Duarte wrote: Thank you jwi, and Jacob, I took a look at that posting and it seems pretty unique. I am not much interested in the speech driven development, but I am very interested in developing an accessible IDE. Well you should be because it looks like an aural interface (uses speech instead of keyboards) uses the same kinds of data to present to either a text to speech or speech recognition driven environment. A professor and I have been throwing around the idea of developing a completely text based IDE. There are a lot of reasons this could be beneficial to a blind developer and maybe even some sighted developers who are comfortable in the terminal. The idea would be really just to provide a way of easily navigating blocks of code using some kind of tabular formatting, and being able to collapse blocks of code and hearing from a high level information about the code within. All tools and features would obviously be spoken or output in some kind of audio manor. I've been working with another professor working on some of these issues as well. His focus has been mostly blind young adults in India. come up with some pretty cool concepts that looks very usable. The challenge now is to make them work and, quite frankly monetize the effort to pay for the development. Again, this shows the similarities in functionality used by both speech recognition and text-to-speech. All I care about is text and what I can say. We're now working with constructs such as with-open, argument by number, plaintext symbol names (with bidirectional transform to and from code form), guided construct generation for things like classes, methods, comprehensions etc. All of these things would be useful to handed programmers as well as a way of accelerating co-creation and editing. Unfortunately, like with disabled people stove piping text-to-speech versus speech recognition, handed developers stovepipe keyboard interfaces and don't really think about what they are trying to do, only how they are doing it. Yes yes, it's a broadbrush that you can probably slap me with. :-) Oh and before I forget does anyone know how to contact Eric who was developing that accessible speech driven IDE? Thanks Well, you could try looking in a mirror and speaking my name three times at midnight But you would get better results if you used my non-mailing list email address. e...@eggo.org. --- eric -- https://mail.python.org/mailman/listinfo/python-list
Re: Accessible tools
Eric, issue is that with screenreaders, we're generally way more into navigating code and interface character by character/by keyboard, so , yes, keeping interface relatively simple is a good thing, but, we also would prefer to primarily keep all interface elements to make use of standard UI controls, and make sure tab index/order is suitable/relevant at times, etc. etc. As in, I think we'd primarily want to avoid having to use a mouse at all if possible, but anyway. Stay well Jacob Kruger Blind Biker Skype: BlindZA Roger Wilco wants to welcome you...to the space janitor's closet... - Original Message - From: Eric S. Johansson e...@harvee.org To: python-list@python.org Sent: Friday, February 20, 2015 7:22 PM Subject: Re: Accessible tools On 2/19/2015 10:33 AM, Bryan Duarte wrote: Thank you jwi, and Jacob, I took a look at that posting and it seems pretty unique. I am not much interested in the speech driven development, but I am very interested in developing an accessible IDE. Well you should be because it looks like an aural interface (uses speech instead of keyboards) uses the same kinds of data to present to either a text to speech or speech recognition driven environment. A professor and I have been throwing around the idea of developing a completely text based IDE. There are a lot of reasons this could be beneficial to a blind developer and maybe even some sighted developers who are comfortable in the terminal. The idea would be really just to provide a way of easily navigating blocks of code using some kind of tabular formatting, and being able to collapse blocks of code and hearing from a high level information about the code within. All tools and features would obviously be spoken or output in some kind of audio manor. I've been working with another professor working on some of these issues as well. His focus has been mostly blind young adults in India. come up with some pretty cool concepts that looks very usable. The challenge now is to make them work and, quite frankly monetize the effort to pay for the development. Again, this shows the similarities in functionality used by both speech recognition and text-to-speech. All I care about is text and what I can say. We're now working with constructs such as with-open, argument by number, plaintext symbol names (with bidirectional transform to and from code form), guided construct generation for things like classes, methods, comprehensions etc. All of these things would be useful to handed programmers as well as a way of accelerating co-creation and editing. Unfortunately, like with disabled people stove piping text-to-speech versus speech recognition, handed developers stovepipe keyboard interfaces and don't really think about what they are trying to do, only how they are doing it. Yes yes, it's a broadbrush that you can probably slap me with. :-) Oh and before I forget does anyone know how to contact Eric who was developing that accessible speech driven IDE? Thanks Well, you could try looking in a mirror and speaking my name three times at midnight But you would get better results if you used my non-mailing list email address. e...@eggo.org. --- eric -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Accessible tools
While not blind, I have an interest in accessibility and answer a number of questions on the Blinux (Blind Linux Users) mailing list. On 2015-02-19 08:33, Bryan Duarte wrote: A professor and I have been throwing around the idea of developing a completely text based IDE. There are a lot of reasons this could be beneficial to a blind developer and maybe even some sighted developers who are comfortable in the terminal. The idea would be really just to provide a way of easily navigating blocks of code using some kind of tabular formatting, and being able to collapse blocks of code and hearing from a high level information about the code within. All tools and features would obviously be spoken or output in some kind of audio manor. It would seem that the traditional Unix-as-IDE[1] would serve you well here. This is my method of choice, and it allows me to pick my components and combine them. I usually use tmux, though GNU screen would do too. Within that, I usually have the following: - vim to edit my code. Though swap in your favorite, whether emacs/emacspeak, ed/edbrowse, joe, nano, or whatever. I know that at least Vim and emacs support folding away blocks of code (what you describe as collapsing) which I usually prefix with a comment that would give you a description of the block - a command-line (I use bash, some prefer zsh or tcsh or whatever) for things like version-control, running my code, and file management (move/copy/delete/rename/link/etc) - a Python command-line REPL that allows me to do quick tests on a line of code as well as well as make extensive use of Python's built-in dir() and help() commands which are invaluable. - when doing web-development (Django in my case), I'll often have the dev-server running in one pane, and a console browser like lynx/links/links2/elinks/w3m in another pane so that I can put my code through its paces Another benefit of this is that I can run this on my development machine, but then SSH into the machine from anywhere, reattach to the tmux/screen session, and have the same configuration right as I left it. The entire tmux/screen session can be run within an accessible terminal window (I know that some are more accessible than others), within a terminal screen-reader session (like yasr, screader, or emacspeak), or even remoted into via an accessible SSH program on your platform of choice. -tkc [1] http://blog.sanctum.geek.nz/series/unix-as-ide/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Accessible tools
Brian, I am also a fully bind python/PHP developer, and all I really bother with, aside from python interpreter itself is the text editor called edSharp: http://www.empowermentzone.com/edsetup.exe That's been developed by another blind guy who's name you might have heard in other circles, Jamal Mazrui, and it's just a programmers text editor that has a bit of extra functionality built in for use along with screen readers like jaws and NVDA, etc. And, there are also some other general blind programmer mailing lists - I am on both progra...@freelists.org as well as a couple of other topic specific ones, but anyway. Stay well Jacob Kruger Blind Biker Skype: BlindZA Roger Wilco wants to welcome you...to the space janitor's closet... - Original Message - From: Bryan Duarte bryan0...@gmail.com To: python-list@python.org Sent: Wednesday, February 18, 2015 7:43 PM Subject: Accessible tools Hello all, I have been posting to another group which directed me to this group. I am a blind software engineering student at Arizona State University. I am currently doing research and have decided to use Python as my developing language. I am in search of an accessible IDE or other tool set which will allow me to use the features with a screen reader. I have tried a number of tools but so far have been unsuccessful in finding one that allows me to use the tools and features of the IDE with my screen reader. I understand that I do not need an IDE to use Python, I am looking for an IDE to allow me to explore the classes and methods easily and quickly. I have tried the following tools. • pyCharm • iPy • iPy Notebook • Idle • and Eclipse So far only Eclipse was accessible but I did still incounter some difficulties like the IDE freezing up when tool tips would pop up. Finally I am using a Mac mostly but can use Windows, or Linux if need be. Thank you and I appreciate any and all suggestions. -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Accessible tools
Dear Bryan, I don’t have a finished solution for you, but I would like to link you to a previous thread on this list: https://mail.python.org/pipermail/python-list/2015-January/696276.html The poster seems to be researching into the direction of developing a speech-friendly IDE. You may want to follow his work. regards, jwi signature.asc Description: OpenPGP digital signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Accessible tools
Thank you jwi, and Jacob, I took a look at that posting and it seems pretty unique. I am not much interested in the speech driven development, but I am very interested in developing an accessible IDE. A professor and I have been throwing around the idea of developing a completely text based IDE. There are a lot of reasons this could be beneficial to a blind developer and maybe even some sighted developers who are comfortable in the terminal. The idea would be really just to provide a way of easily navigating blocks of code using some kind of tabular formatting, and being able to collapse blocks of code and hearing from a high level information about the code within. All tools and features would obviously be spoken or output in some kind of audio manor. Jacob, I know your name and I do know Jamal's name as well. I think I recall your names from either back in the Mobile Speak days, or maybe from the jaws mailing list. Either way thank you for the feedback and I will take a look at edSharp today. The Python interpreter is great for small tests or scripts but for lengthy programs there is no easy way to save your code other than capturing the entire history with extra code and all. How do you typically handle that issue? Thank you both. Oh and before I forget does anyone know how to contact Eric who was developing that accessible speech driven IDE? Thanks On Feb 19, 2015, at 3:08 AM, Jonas Wielicki jo...@wielicki.name wrote: Dear Bryan, I don’t have a finished solution for you, but I would like to link you to a previous thread on this list: https://mail.python.org/pipermail/python-list/2015-January/696276.html The poster seems to be researching into the direction of developing a speech-friendly IDE. You may want to follow his work. regards, jwi -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Accessible tools
I use edSharp as my primary code/text editor, and just save code from there, and while it doesn't offer too many things like design tools, it's pretty much perfect in terms of code block selection, code snippets, code navigation - to a certain extent, even in python, with regards to jumping from block to block, etc. Text based IDE would be nice at times, as long as you could review code nicely enough, etc., and in terms of GUI design I generally just make use of/work with scrollable grids via wxPython, since that cooperates well enough in end result with both sighted, and accessibility API users, etc., but anyway. It just means my interface design is done via a form of layout-by-code, dropping controls in a flexGridSizer as well, but anyway. My one primary thing I would like to be able to handle in terms of development process is better means of working with debugging code execution, etc. - at moment, primarily either print out information to console, during dev process, or at times invoke sound effects/TTS output to keep track, or even, occasionally use pickle to store images of objects for later review, etc., but anyway...smile Stay well Jacob Kruger Blind Biker Skype: BlindZA Roger Wilco wants to welcome you...to the space janitor's closet... - Original Message - From: Bryan Duarte bryan0...@gmail.com To: Jonas Wielicki jo...@wielicki.name Cc: python-list@python.org Sent: Thursday, February 19, 2015 5:33 PM Subject: Re: Accessible tools Thank you jwi, and Jacob, I took a look at that posting and it seems pretty unique. I am not much interested in the speech driven development, but I am very interested in developing an accessible IDE. A professor and I have been throwing around the idea of developing a completely text based IDE. There are a lot of reasons this could be beneficial to a blind developer and maybe even some sighted developers who are comfortable in the terminal. The idea would be really just to provide a way of easily navigating blocks of code using some kind of tabular formatting, and being able to collapse blocks of code and hearing from a high level information about the code within. All tools and features would obviously be spoken or output in some kind of audio manor. Jacob, I know your name and I do know Jamal's name as well. I think I recall your names from either back in the Mobile Speak days, or maybe from the jaws mailing list. Either way thank you for the feedback and I will take a look at edSharp today. The Python interpreter is great for small tests or scripts but for lengthy programs there is no easy way to save your code other than capturing the entire history with extra code and all. How do you typically handle that issue? Thank you both. Oh and before I forget does anyone know how to contact Eric who was developing that accessible speech driven IDE? Thanks On Feb 19, 2015, at 3:08 AM, Jonas Wielicki jo...@wielicki.name wrote: Dear Bryan, I don’t have a finished solution for you, but I would like to link you to a previous thread on this list: https://mail.python.org/pipermail/python-list/2015-January/696276.html The poster seems to be researching into the direction of developing a speech-friendly IDE. You may want to follow his work. regards, jwi -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
