GNOME Bugzilla – Bug 651206
If Orca preferences dialog enabled the contracted braille feature, not possible choosing Orca present uncontracted form the cursor selected word or not
Last modified: 2018-02-08 12:57:51 UTC
Dear Developers, Now, if Orca enabled the contracted braille feature, only presenting contracted form the text in braille display if the cursor does'nt positioned a text part. If the cursor presenting a new line when the user scrolling for example the braille display, the cursor highlighted word is presenting with uncontracted format. Of course, this situation the contracted braille indicators is not presenting (for example capsign). This is partialy good for example with text editing, but some time need choose full contracted presenting format. Some situations with perhaps need this switch way: If only need reading for example a book, and not need editing the text, possible better if all contracted word is displaying, independent the cursor position. Of course, need keep default enabled the now used method if contracted braille is enabled, if future will be have a setting switch possibility to toggle this mode on/off if contracted braille feature is enabled. Some situations with perhaps better showing all words with contracted form, independent the cursor position: For example, when I only reading a text, and using cursor movement keys my braille display, some time I would like reading entire text with contracted form. If for example the cursor have a first place with a line, and I only scrolling the braille display the text, I always not see first word with translated form if the word have new line and positioned the cursor with new line word. Another interesting example if the user reading only an e-mail, and not possible editing the text. Easy possible reproducing this problem with following way, if you doing a test e-mail with your address: Simple put contracted words with line by line, and scroll the contracted words when you get the e-mail for example in Thunderbird. So, perhaps some time practical switch the reading mode in braille display if possible implementing this setting. This default mode now producing problems for example in Firefox when the user reading an article in a webpage: For example, yesterday I readed an article with Firefox, when the cursor positioned a new line, the first word general not applied the contracted form. The page not have possibility to edit the text. For example, in article if the cursor positioned a number, the numbersign is not presenting, the numbers is presenting with computer braille format. This is I reproduced too with Gedit the following text: 123 456 When I positioning the first line, and scrolling braille display with next line, I see the next line have number with computer braille format. If I go back the prewious line with braille display, I see prewious line have number with computer braille format too. If not possible doing this cursor uncontracted mode switch a braille binding, need doing a setting, and a gui preference with Orca GUI preferences dialog/braille page the user have possibility to choice what presenting mode he prefer if contracted braille is enabled. Default need keeping on this preference with compatibility purpose on or off, depending the future check box label. Attila
Created attachment 189011 [details] [review] A possible fix Please review this patch. I doed a setting and a check box above the contraction table combo box with Orca gui preferences dialog/braille page. If the check box is checked, Orca full right presenting the cursor highlighted word with uncontracted format. Compatibility purpose this is the default setting. If the check box is unchecked, right all words presenting contracted format, independent the cursor highlighted word. The cursor offsets this situation is good too. For example, if I uncheck this check box, and editing text, if I writing more capital beginning words, the cursor right offsetting the capital beginning letter, not the capital sign indicator. I reported this issue with an another bugreport. I tested this fix with Firefox, Thunderbird, and normal text editing (simple reading the edited text with contracted format). If the patch is good, please commit the patch. Unfortunately this fix way patch if good not possible commit with Orca 3.0 maintenance version. Attila
Have a problem my fix way: If I opening for example with gedit, and only read the text, not have problem the fix. But when I type for example a line first any number, the numbersign indicator is not presenting if the future check box is unchecked. If the first character is not a number, the problem is not happening, but the first character of a line is removed the display. For example, this problem doesn't happening with Thunderbird. I will be attaching a debug output file. Attila
Created attachment 189061 [details] This debug.out possible show why happening the problem
Hy Joanie, I little try modify my patch to I see why offsetting wrong place the cursor. I see interesting experiences, I summary what can I detect. last trying to prowide right cursor position all situations with src/orca/braille.py file the contractLine function: if not expandOnCursor or cursorOnSpace: mode = 0 else: if settings.showcursorComputerBraille==True: mode = louis.compbrlAtCursor else: mode = 0 contracted, inPos, outPos, cursorPos = \ louis.translate([self.contractionTable], line, cursorPos=cursorOffset, mode=mode) # Make sure the cursor is at a realistic spot. # #cursorPos = min(cursorPos, len(contracted)) if len(line)<len(contracted): cursorOffset=len(contracted)-len(line) cursorPos = min(cursorPos, len(contracted)+cursorOffset) debug.println(debug.LEVEL_FINEST, "cursor position: "+str(cursorPos)+", contracted line: "+contracted) else: cursorPos = min(cursorPos, len(contracted)) debug.println(debug.LEVEL_FINEST, "cursor position: "+str(cursorPos)+", contracted line: "+contracted) return contracted, inPos, outPos, cursorPos When I only reading and scrolling the text with braille display, and the present cursor highlighted text with uncontracted format check box is unchecked, everything is working fine. I see right all texts with contracted braille. But, my fix method have a problem with some applications, for example gedit: For example, if I write gedit the Alma 1 text, the cursor is offsetted wrong place if the text have first line. Not seeing the braille display the capital sign indicator, and the a letter. If I write only a number with 0 cursor position, not seeing the numbersign indicator. Some modified debug.out examples: 1. Only the Alma word have wrote: cursor position: 5, contracted line: $alma VISIBLE: 'alma $l', cursor=5 2. Alma word and space wrote: cursor position: 6, contracted line: $alma VISIBLE: 'alma $l', cursor=6 3. Alma, space and one number wrote: cursor position: 8, contracted line: $alma #a This value is right, because before the 1 number need presenting a numbersign indicator the braille display. But visible line now have difference with cursor position, I need quote the braillegenerator debug part: required=[] cursor position: 0, contracted line: cursor position: 8, contracted line: $alma #a isReadOnlyTextArea=False for app.name='gedit' name='None' role='text' state='editable enabled focusable focused multi line sensitive showing visible' relations='' readOnly=[] cursor position: 0, contracted line: cursor position: 8, contracted line: $alma #a nodeLevel=[] cursor position: 0, contracted line: cursor position: 8, contracted line: $alma #a generate braille results: Component: 'gedit $alkalma2"s', 0 Region: ' ', 0 Component: '*#a/ mentetlen dokumentum - gedit $keret', 0 Region: ' ', 0 Component: '$laplista', 1 Region: ' ', 0 Component: '*#a/ mentetlen dokumentum $lapf{l', 0 Region: ' ', 0 Component: '$gqrd|thet7 ablakt"bla', 1 Region: ' ', 0 Text: '$alma #a $l', 8 BRAILLE LINE: 'gedit $alkalma2"s *#a/ mentetlen dokumentum - gedit $keret $laplista *#a/ mentetlen dokumentum $lapf{l $gqrd|thet7 ablakt"bla $alma #a $l' VISIBLE: 'lma #a $l', cursor=7 This is a very long braille line with Orca sending the braille display. Because Orca always presenting the application related informations if the cursor have the first line when I typing, only I think not fit the first line right the braille display when I typing a text. When I scroll back the braille display with left, I see the application related informations, and missing text parts with braille display (capsign indicator, and the first capital letter). This is the braille context with Orca send the braille display. If I only trying this with a number with first line, I see right end of my braille display the numbersign indicator before real line with containing the number when I scroll back one line the braille display. So, real text is begin presenting wrong place, and not separated with braille context. This is interesting, because if I repeating this test typing for example the second line, everithing is presenting right the braille display. If I writing a number, right presenting the numbersign indicator, if I writing line beginning a capital beginning word and a number after space character, right presenting the capsign indicator before the capital letter, and numbersign indicator before the typed number. If I writing first line a blank line, and repeating the test, every tested things presenting right. I think this is an another bug and independent my cursor offset related modification trying or the first attached patch. Main purpose my fix to possible reading texts with full contracted format. This is done my first attached patch the #651206 bugreport. When I browsing for example the web and reading articles, I always this way reading the articles. But if this is possible I would like doing a flexible way to edited text presenting too with contracted format right if unchecked the present cursor highlighted word with uncontracted format check box. If I disable the enableBrailleContext preference with user-settings.conf file, every typed text with the first line presenting right with contracted format if I uncheck the present cursor highlighted word with uncontracted format check box. The now showed cursor offset modification related code is not need, factory used cursor offset way is full right. My question: How can possible resolving this issue? Some time the presenting braille context informations is very need. With pyatspy.role_text and similar widgets related, need separating the braille context and real text for example with a \n character after Orca sending the braille display the braille context, and begin presenting the real typed text with 0 cursor position? Or need doing a gui check box this setting?
Created attachment 189625 [details] [review] A cleaner patch This patch is cleaner implementing this function. I have got only one question before doing after jul 4th the final patch: If the user-settings.conf file not existing the "showcursorComputerBraille" setting any place, happening following traceback error message when I try presenting Orca GUI preferences dialog: Traceback (most recent call last):
+ Trace 227432
module.showPreferencesUI()
orca_state.orcaOS.init()
self._initGUIState()
prefs["showcursorComputerBraille"])
How can possible prewent this type problem general if need doing a new setting and a gui setting possibility for orca GUI preferences dialog? I forgot doing anything?
If any developer have a little time, please review my last patch to I known I going right direction this bug fix. Your openion have chance to awailable this feature with final Orca 3.2 version? If yes, this bug fix increasing braille reading feeling for Orca if contracted braille feature is enabled.
Created attachment 200393 [details] [review] A new revision, with handled the prewious wrote traceback error message with GUI widget initalization This patch is the orca-xdesktop branch compatible patch, but I think this is the final version. I handled the prewious comment wrote traceback error message, thank you Joanie your help. Hopefuly this problem fixing way is acceptable if the user user-settings.conf file not existing yet the proper setting. I tested this problem after I deleted this feature related settings in my user-settings.conf file, Orca GUI Setup dialog proper presenting the screen, and the check box is proper initialized with checked state. Next week I will be try this patch under GNOME3. Attila
Created attachment 200522 [details] [review] This is the master version compatible patch Joanie, I possible little tired now, but I don't understand a think for GNOME3 compatible patch related, please write a little answer me what can I doed wrong this patch. The problem is following: If the user-settings.conf file not existing already the showcursorComputerBraille setting, when I opening Orca preferences dialog and simple click Ok button, this new setting doesn't adding orca in my .local/share/orca/user-settings.conf file. The patch is equals with the orca-xdesktop branch yesterday attached patch, only the UI file related modification place is different, and experimental purpose I changed the src/orca/settings.py file the default setting value from True to False with showCursorComputerBraille setting. For example, in orca-xdesktop version the yesterday attached patch works perfect if this setting are not existing the user-settings.conf file my Ubuntu Lucid system. If I remove my .local/share/orca directory the user-settings.conf file, the setting is proper created the new stored file, but if I manualy remove this setting to I see what will be happening if this setting not existing factory level with an oldest existing user-settings.conf file, I see the described problem. I think the mistake perhaps have in orca_gui_prefs.py file, but I don't see any traceback error message because I handled the important exception if the setting is not existing the user configuration file. Can you confirm this problem your GNOME3 system? My testing Oneiric system is not always working right, future need the reinstalling. Attila
Joanie, if you have a very little time, I would like please a short review the GNOME3 related patch implementation I would like fixing remaining issues this function related with detecting the reviewing and attach the final stable patch. If I known what can I mistake the GNOME3 related patch, next year January I would like finalizing the braille position index feature code and the braille mnemonic presenting related feature code, and would like attach the GNOME3 compatible patches this new enhancements. What the final date next year before UI freeze is beginning? I very would like awailable next Orca version this three functions if this is possible. Attila
Hy Joanie, Can you short reviewing my patches this bugreport related? :-):-) Of course I not impatient, but only have one month before UI freeze, and I would like finalizing this feature related codes if you tell me what need I changing this bugreport attached patches before you commit the final patch. Attila
Peter Torpei wrote following letter in Orca-list with related this bugreport: "Using Vinux with Orca, I have braile Grade 2 translation turned on. I notice that the word where the focus is always has Grade 2 translation turned off and appears in Grade 1. I didn't see any setting in any of the Orca dialogs for braille that would let me have an entire line translated into Grade 2 braille without expanding the word with focus into Grade 1. Is there an option some place for this? Thanks. --Peter" Joanie, if I now not change UI interface (only have a setting this mode switch temporary on/off) because already have UI freeze, possible committing a fix both master branch and orca-xdesktop branch? Future absolute sure need doing a gui widget the Orca preferences dialog/braille page to users easyest change this new setting, but this is only possible with master branch when next development version developing beginning. Attila
Comment on attachment 200393 [details] [review] A new revision, with handled the prewious wrote traceback error message with GUI widget initalization This seems to be obsoleted by the next patch.
Review of attachment 200522 [details] [review]: I will need to investigate liblouis' settings here before I am willing to commit this -- or a cleaned up version thereof.
Hy Joanie, Following link possible quickly help: http://liblouis.googlecode.com/svn/documentation/liblouis.html#lou_005ftranslateString A little part the documentation with based my patch the lou_translate function: "5.6 lou_translate int lou_translate ( const char * tableList, const widechar * const inbuf, int *inlen, widechar * outbuf, int *outlen, char *typeform, char *spacing, int *outputPos, int *inputPos, int *cursorPos, int mode); This function adds the parameters outputPos, inputPos and cursorPos, to facilitate use in screen reader programs. The outputPos parameter must point to an array of integers with at least inlen elements. On return, this array will contain the position in outbuf corresponding to each input position. Similarly, inputPos must point to an array of integers of at least outlen elements. On return, this array will contain the position in inbuf corresponding to each position in inbuf. cursorPos must point to an integer containing the position of the cursor in the input. On return, it will contain the cursor position in the output. Any parameter after outlen may be NULL. In this case, the actions corresponding to it will not be carried out. The mode parameter, however, must be present and must be an integer, not a pointer to an integer. If the compbrlAtCursor bit is set in the mode parameter the space-bounded characters containing the cursor will be translated in computer braille. If the compbrlLeftCursor bit is set only the characters to the left of the cursor will be in computer braille. This bit overrides compbrlAtCursor. The ucBrl (Unicode Braille) bit is used by lou_charToDots and lou_translate. It causes the dot patterns to be Unicode Braille rather than the liblouis representation. lou_dotsToChar and lou_backTranslate recognize Unicode braille automatically. The otherTrans mode needs special description. If it is set liblouis will attempt to call a wrapper for another translator. These other translators are usually for Asian languages. The calling sequence is the same as for liblouis itself except that the trantab parameter gives the name of the other translator, possibly abbreviated, followed by a colon, followed by whatever other information the other translator needs. This is specific for each translator. If no such information is needed the colon should be omitted. The result of calling either the translate or back-translate functions with this mode bit set will be the same as calling without it set. That is, the wrapper for the other translator simulates a call to liblouis. Note that the wrappers are not implemented at this time. Setting this mode bit will result in failure (return value of 0)." Attila