Re: The top three big problems, Summing up # 1
- From: "Marlon Brandão de Sousa" <splyt.lists@xxxxxxxxx>
- To: programmingblind@xxxxxxxxxxxxx
- Date: Sun, 14 Oct 2007 13:02:21 -0300
Andy:
1. A way to navigate in such a way that you can quickly jump between
pertinent program constructs. (End of method, end of block, beginning
of block, beginning of method). (Marlon, Will)
Splyt:
Yeaah. This is, for me and I beleave for most part of us, the main
feature wanted. Not only these examples, but also next declaration,
next definition and so forth. Another thing usefull is a list of
available things, like jaws scripting does. If you hit a keystroke a
nice listview appears with all the available functions. You choose one
and press enter and its call is inserted at the point the cursor is
placed in. So If I need to call a method, from a class which has 50
methods, and I don't remember exactly how it spells, I could use a
list of methods and choose the one I want. A button would insert a
method call at the cursor point, another button would place me right
on the method definition line. It is great to navegate by previous and
next method keys, if you want to take a look on what the file has, but
it is not so cool to press the next method keystrock 34 times till you
arrive at the method you need to edit. Having a list of methods from
where you can choose one is great. In fact, JAWS used this aproach
very well with the list of links in internet navegation. So I would
say, for item one, all you said plus providing lists of every
pertinent program constructs. Note that the next / previous features
and the list feature doesn't exclude each ther, they complement each
other and should be provided together.
Andy
The debugger I've created allows you to "navigate" the execution of a
program, backward and forward. It sounds like it would be much more
useful if you could also, with the keyboard, navigate back and forth
between major events too, like "jump back to the beginning of the
method" or " jump to the end of this block. Code that isn't running in
the debugger could probably allow you to navigate in the same way,
making the interface aurally consistent, and navigationally
consistent, for both running and non-running programs, just the
program "speaks" different information. At runtime, it gives you
information about the values of variables, control flow, etc, but
while not at runtime it gives you static information.
splyt:
Seen good.
Andy
2. Construct Preview.
Not sure what to call this idea. What if, while you are debugging or
while your cursor is at some position in the code, you can get a
preview of "what is left" in the rest of the block or the method.
Marlon, and others, suggested things like collapsing methods would be
cool. I'm thinking, perhaps if you can preview what's ahead of the
cursor, and what is behind, that this might simulate "hiding" of code?
For example, would statements like, "There are 10 statements left in
this method?" or something equivalent, be useful at all? (Maybe not)
Any other ideas for how to "hide" code using audio?
splyt:
I don't think the "there're ... statements" would be personally
usefull. Keystrokes to next and previous structures already would
achieve this. If I am in the beginning of a if block and I don't want
to read it I would hit the end of block keystroke ad I would be put at
it. Similarly, if I don't want to read the rest of the method anymore
I would hit the end of method keystroke and would be placed right
after the } of the method. I think item 1 would take care of this.
But, as for debugging, it would be usefull in the seense that I can
ask the debugger to read the rest of the method lines with all
variable values already pointed out, so I would follow what is
happening, much like a sighted one does when they pass the mouse
through the lines of code and variable values are shown.
Andy
3. Optional ways to read the code, depending upon the context.
(Veli-Pekka Tätilä )
It sounds like, sometimes you want the spoken text to include words
that give you the semantics of what is happening in the program, while
other times you want the no frills syntax so you literally know what
to type. What about a suggestion like this:
You have two sets of key combinations. One shortcut will read the
syntax to the left or right of the cursor raw. Another shortcut could
read the semantics of the left or right syntax. For example, maybe
something like:
a * b, the cursor, if it were right before the b, could read either
"multiplication" or "asterisk," while the phrase
*p * b. If the cursor is right before the second asterisk, in the
language C, it could read, "pointer p" or "asterisk p," depending on
what key combination you pressed. This is a cool idea, I think because
it could adapt to whatever programming language you are using, to tell
you not only the syntax, but what the syntax means. What do you think?
splyt:
This is good. You should however to provide a way of changing the mode
so one can use the standard keystrokes to read the text. It works this
way:
For reading the current line I use ins + up arrow. For reading the
next line, I use down arrow. For reading the left word, I use ctrl +
left arrow. These are pretty standard keystrokes, and they could be
used to read the text as it is (without interpreting). If one wants to
read a line interpreted, they could use aanother keystroke. But, if
they decide they want to read all the code interpreted anyways, they
would press a "alter reading mode" keystroke, and then the standard
reading keys (ins + up arrow, down arrow, etc) would be used to read
interpreted code, while the keys used to read interpreted code before
now would read the real code.
Andy
4. Easier navigation of errors. (Marlon)
Right now I've got a multiline textbox representing compiler errors,
etc. If you could choose any system for how you access errors from
this box, how would you do it?
Like, should I just include a key combination that navigates you to
the box, then have another combination that reads the next error or
the previous error?
splyt:
ctrl + e places you in the next line marked as being wrong, ctrl +
shift + e places you on the previous line marked as being wrong. ctrl
+ r says the error.
ctrl + l places you in the list of errors window. This window has a
list box containing in each item the error type (linker / compiler
etc), the code of the error and a short dexcription. Pressing tab you
would be placed in a memo containing all the selected error
description. Enter would place you right in the line where the error
is located.
Andy
Great conversation, thanks for the feedback everyone. For sighted
person like myself, this type of information is solid gold.
splyt:
You're well come. Please feel free to send me an e-mail if you wish to
add me on skype or another instant messaging program.
Marlon
2007/10/14, Andreas Stefik <stefika@xxxxxxxxx>:
--
When you say "I wrote a program that crashed Windows," people just
stare at you blankly and say "Hey, I got those with the system, for
free."
Linus Torvalds
__________
View the list's information and change your settings at
//www.freelists.org/list/programmingblind
Other related posts:
