Re: [orca-list] Calling all braille users. I need your opinions.

[Jacob Schmude <j schmude gmail com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi
Agree about using the control key to instantly dismiss a flashed
message. Also, the title bar fixes do seem to work properly both for
speech and braille. I generally keep my progress bar update set to 5
seconds, though in some apps with a lot of useless progress bars I turn
it off completely.

On 05/10/2010 03:38 PM, Joanmarie Diggs wrote:
> Hi Jacob.
>
> On Mon, 2010-05-10 at 06:17 -0400, Jacob Schmude wrote:
>
> > I think single seconds would be enough. However, you don't have to
> > present them in a list.
>
> I wasn't planning to. I'm going to have an editable spin button which
> generates the options. That way, users can type what they want or arrow
> or page down.
>
> > I'd probably change the default length
> > of 5 seconds to perhaps 3 seconds, unless we can press a key to
> > interrupt flashed messages. 5 seconds is usually a bit long to wait.
>
> [...]
>
> > However, we should be able to interrupt the flashed message with a key
> > if we choose to.
>
> You can indeed press a key to interrupt flashed messages. If you press
> any key, Orca responds -- which in almost all cases results in updated
> braille because Orca will display the item with focus, the newly
> selected item, the item you just moved to in flat review, etc. You can
> give it a try now using master. All of the "not found" structural
> navigation messages are (or should be) flashed. Same for the title bar,
> status bar, and default button info.
>
> If you find cases where we're displaying that info and pressing a key
> doesn't update the braille display/get rid of the flashed message,
> please let me know.
>
> Having said that, something perhaps we could consider doing, is having
> Control restore the braille display. While any key interrupts speech, I
> suspect most of us are in the habit of using Control as our
> shut-up-speech go-to key. (right?) If so, that might be the logical,
> discoverable solution. Thoughts?
>
> > Don't forget Openoffice help. Orca isn't brailling any of the items in
> > the tree view there. Sometimes the string "TREE LEVEL 1" gets brailled
> > but nothing more than that.
>
> Dang. Good to know. I'll look. Thanks!
>
> As a related aside, a while back someone... who was it? Jason,
> perhaps?? ... anyway, someone asked me what all the areas of
> braille-speech inequality were. And at the time, what occurred to me is
> that once we start looking, talking, and working on this, we'll find all
> sorts of things we aren't presenting in braille -- beyond those things
> which I'm already aware of. Guess I was right.... (Kinda wish I
> weren't.) Anyhoo, please keep these reports coming in. We'll get them
> all resolved.
>
> > > * Progressy updates. There are two such categories: Spoken messages to
> > > let you know an app is busy ("loading please wait", "finished loading")
> > > and actual progress bars. Personally, I'd flash the former
> > > automatically; I'd flash the latter at the same time we were speaking
> > > the percentage.
> > Agree on this one. We can always rest the flat review on a progress bar
> > if we want to see realtime updating.
>
> Out of curiosity, what do you have your progress bar interval set to?
> The reason I ask is that for testing progress bar issues in general, I
> set mine from the default 10 seconds to 3 seconds. At that rate and with
> a 5 second flash time, my display was all progress bar updates all the
> time. Personally, I could see a case where I'm reading in braille, but
> keeping an ear out (so to speak) for speech updates. I think we may need
> to do the percentage updates for progress bars totally separately.
> (Perhaps even having a separate interval and enable/disable updates for
> braille? I dunno. I'm open to suggestions.)
>
> > Actually, these are rather erratic. Sometimes it will braille the title
> > bar and not speak it, other times it will speak it but not braille it.
> > Take Totem, GNOME's movie player. Use the title and status bar keys, and
> > nothing gets brailled even though the proper information is spoken. Now,
> > take gnome-mplayer. The title and status bar keys braille it, but they
> > don't speak it.
>
> I checked in a fix/change for the title and status bars. I'd be
> interested in knowing what you think.
>
> But in terms of your observation, what was happening before is that Orca
> was doing an updateBraille on the locusOfFocus. Whatever the
> locusOfFocus was, that's what got displayed. Then it found the title bar
> or status bar and spoke it. Now whatever we get in this case we speak
> and braille. If we fail to do those things, that means we could not
> locate the title bar or status bar and a custom script will need to be
> created (or modified) to give Orca the ability to locate that
> information. Filing bug reports for those occurrences would be most
> appreciated.
>
> Thanks for all your help with this!
> --joanie

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvoY2wACgkQybLrVJs+Wi4I4ACeJpyriYgxhO2ONTRlh7sru0Cn
AkUAmQG8xqEm/v6+NurD5VFX22s8sDH0
=6dWJ
-----END PGP SIGNATURE-----