GNOME Bugzilla – Bug 400732
[mike][requirement] Toggle between logical and screen braille presentations.
Last modified: 2018-02-08 12:21:48 UTC
It should be possible to toggle the braille view between a logical representation of the item with focus and a simple view of the current screen line.
See also bug 436888 as a means to get us some level of information similar to this when in flat review.
From our meeting last Friday on this, Mike will be updating the refreshable braille section in the Orca spec related to this, to include: 1/ Change all occurrences of "screen layout" to "window layout". 2/ Describe how to handle the display of titlebar information. 3/ Add a delineating character between adjacent object (by default a space). This delineating character can be changed to something else. 4/ Need to describe how to handle vertical scrollbars. 5/ How is focus handled? 6/ Settings for defining "end of text" marker and "begin/end of window" marker. 7/ Add OpenOffice to the "Why does this just apply to GTK, Java, and web applications" line. Since then I've thought of a couple more questions. 1/ Will there be an option on one of the panes in the Orca preferences dialog, that allows you to set your preferred braille representation? If so, what should it look like and where should it go? 2/ Will there be a keyboard shortcut to toggle the current braille representation? If so, what should that be? The spec should probably also updated to include this information. Thanks.
(In reply to comment #2) > From our meeting last Friday on this, Mike will be updating the > refreshable braille section in the Orca spec related to this, > to include: > 1/ Change all occurrences of "screen layout" to "window layout". done > 2/ Describe how to handle the display of titlebar information. done > 3/ Add a delineating character between adjacent object (by default > a space). This delineating character can be changed to something else. I'm still not sure I like this idea > 4/ Need to describe how to handle vertical scrollbars. done > 5/ How is focus handled? I can't remember what you were looking for here. > 6/ Settings for defining "end of text" marker and "begin/end of window" > marker. I haven't figured out what should be used here yet. > 7/ Add OpenOffice to the "Why does this just apply to GTK, Java, and web > applications" line. done > 1/ Will there be an option on one of the panes in the Orca preferences > dialog, that allows you to set your preferred braille representation? > If so, what should it look like and where should it go? Yes, I've added this info to the spec > 2/ Will there be a keyboard shortcut to toggle the current braille > representation? If so, what should that be? Yes, I need to figure out what brltty command this should map to. The spec should now be up to date except for the above comments and questions.
>> 5/ How is focus handled? > I can't remember what you were looking for here. If I remember correctly, this was to state whether moving around in window mode would affect the locus-of_focus. Will, is that how you remember this? Mike, in email you said "...still waiting for a couple small comments from you." What's the other one you need my input on?
(In reply to comment #4) > >> 5/ How is focus handled? > > I can't remember what you were looking for here. > > If I remember correctly, this was to state whether moving around in > window mode would affect the locus-of_focus. Will, is that how you > remember this? Yep!
The spec has now been updated.
From our meeting today, here are the list of spec updates that are needed. 1/ Need to define special characters a) Begining of object - "" (empty string) b) End of object - "" (empty string) c) Object delimiter - " " (space) d) Begining of line - "" (empty string) e) End of line - "$l" f) Line break - ?? (to be determined) g) End of text line - ?? (to be determined) 2/ Keyboard shortcut to toggle the current braille representation. Need to figure out what the brltty command that this should map to. 3/ Need to add a paragraph describing how trees are handled. (Might need to add a paragraph describing the generalization of all these types of object; i.e. selectable objects). 4/ Restrict braille moving the focus to multi-line text areas. 5/ Vertical scrollbars should be presented when they first occur. Thanks.
Created attachment 95144 [details] [review] Patch to provide Preference GUI and settings. Backend stuff to expose this via GUI and preferences. Nothing to really try yet. Not committed.
My notes after talking with Will on how best to implement this. 1/ Looks like most of the work will be done in getBrailleRegions() in flat_review.py. Will need to add an extra parameter for isWindowMode. If set, then we will add in Regions for all the various delimiters. 2/ In getBrailleRegions() in flat_review.py, only put object delimiters around "complete" objects. In other words, don't separate objects from their labels. 3/ In default.onWindowActivated (and onFocus for role == FRAME), if we are in braille WINDOW mode, get the flat review context and save it in self.flatReviewContext (rather than in focus_tracking_presenter.py). 4/ In toggleFlatReviewMode(), prevent context destruction (self.flatReviewContext = None) if we are in WINDOW mode. 5/ The __updateWindowBraille() routine in default.py should call updateBrailleReview(). 6/ When user changes focus in WINDOW mode, need to update context. This will be with setCurrent() in flat_review.py In order to use setCurrent(), we need to turn an accessible object into lineIndex, zoneIndex, wordIndex, charIndex variables. In the flat-review.py _init() method, there is code at lines 574 - 660. that can probably be pulled out and called getLocationFromAccessible() (returning line, zone, word and char indices) and used to get this information. 7/ Handle the special spec. cases in the __updateWindowBraille() routine in default.py. If menu bar or menu etc.., don't call updateBrailleReview() but do special code. (Might be able to do something similar to the code in getBrailleRegions() in braillegenerator.py, when groupChildren=True. Adjust enableBrailleGrouping to True to see the effect.)
Not sure if this should be a separate bug or not. So jotting it down here for now. At CSUN Mike and others pointed out that it would be useful to indicate things like right aligned text (e.g. in a Writer document) as such on the braille display. Indented text would, I assume, fall under this same category.
I am using a voyager 40 cell display, and notice 3 status cells when orca is in control. They are displaying "ttt" They dont seem to change. Maybe they can be used to communicate information? I am not sure if brltty sets aside status cells for all its supported braille displays.
Jon, I had a Voyager a while back. What I did was to turn off the status cells in brltty to allow the whole display to be used for text. We really don't have any current plans for status cells but could consider such a feature in the future.
This particular patch does just what Rich says, which is add the GUI components to set the preference for braille layout style. The code to honor that preference setting still needs to be written. Just a side note -- I'm going through our unreviewed patches and making sure they've been at least looked at. So, you might see some benign comments like the above. :-)
I put the OSM bug on the list for 2.28. If we do that, this RFE should hopefully be easy to implement (famous last words, of course).
We are late in the 2.28 release cycle and I want to focus on "high impact"/"low risk" items that also fall within the release team's restrictions in place. Regretfully, this bug doesn't fit well within those constraints and we'll review it for the 2.29 release cycle.