GNOME Bugzilla – Bug 534022
The Line-end symbol (46 123) should be configurable per application
Last modified: 2009-03-10 00:05:16 UTC
Orca uses a line-end symbol (dots 46-123) to indicate to the user that there is no more text on the current line, and therefore no need to scroll to the right. I am developing an application that transcribed musical scores to braille music notation. However, when reading braille music notation with Orca, the line-end symbol of Orca is confusing since the braille music standard does not define this character and it might be misinterpreted by a user as a musical symbol. Therefore, we need a way to display the line-end symbol used by Orca on a per-application basis.
Created attachment 111229 [details] [review] Initial patch to add orca.settings.disableBrailleEol This patch adds a Orca setting (disableBrailleEol) which defaults to False. We already disable the EOL symbol if we are doing contracted braille. This patch just adds a orca.settings variable (and makes it per-app configurable) for turning EOL symbols off in certain apps. What is missing is the GUI part of things, i.e., the setting is not editable yet in the orca app preferences GUI. But the patch is tested, putting orca.settings.disableBrailleEol=True in ~/.orca/app-settings/freedots.py disables the EOL symbol in my braille music transcriber FreeDots.
Created attachment 111300 [details] [review] Updated proposed patch including setup GUI integration This patch also adds the necessary glade bits to make braille EOL configurable in the orca preferences GUI. It also includes a ChangeLog entry for your convenience.
Created attachment 112981 [details] [review] patch v3 This patch removes two constants from braillegenerator.py, and one flat_review.py; replacing by brailleEOLIndicator variable which lives in settings.py, making it easier to override in personal settings. Have not included gui entry for this, we dont want to overload the user with too many options.
Created attachment 113145 [details] [review] revised patch, to remove bug, needed to modify orca_prfs.py to output string rather than plane value.
Created attachment 113868 [details] [review] Revised patch that tests and pylints This patch is a modification of the previous patches -- it pylints and regression tests well. It also updates the use of the EOL character in the Gecko script. Mario - I made one logic change. Instead of using 'or' in the following: if not self.contracted or not settings.disableBrailleEol: self.string += self.eol I used an 'and': if not self.contracted and not settings.disableBrailleEol: self.string += self.eol The problem was that I was always getting the EOL indicator if I wasn't using contracted braille. Was it your intent to always use the EOL indicator when using uncontracted braille or was that just an honest simple mistake?
(In reply to comment #5) > Created an attachment (id=113868) [edit] > Revised patch that tests and pylints > > This patch is a modification of the previous patches -- it pylints and > regression tests well. It also updates the use of the EOL character in the > Gecko script. > > Mario - I made one logic change. Instead of using 'or' in the following: > > if not self.contracted or not settings.disableBrailleEol: > self.string += self.eol > > I used an 'and': > > if not self.contracted and not settings.disableBrailleEol: > self.string += self.eol > > The problem was that I was always getting the EOL indicator if I wasn't using > contracted braille. Was it your intent to always use the EOL indicator when > using uncontracted braille or was that just an honest simple mistake? > Note also that with this patch, the EOL indicator will always be used regardless of the disable EOL setting. Is that intended behavior as well?
Created attachment 113929 [details] [review] patch so that disableBrailleEOL is respected update to Will's patch, now we respect the settings.disableBrailleEOL. pylints to 10.00
(In reply to comment #7) > Created an attachment (id=113929) [edit] > patch so that disableBrailleEOL is respected > > update to Will's patch, now we respect the settings.disableBrailleEOL. > pylints to 10.00 I see two main diffs: 1) All calls to braille.Text are surrounded by conditionals for whether or not to pass in the EOL indicator or not. I'm not sure this is necessary since the inside of braille.Text already has this conditional. Jon - were you seeing bad behavior that made you add this extra code, or was it just my stupid comment #6? 2) flat_review.py has a new conditional to pull out the EOL. I tried this in an earlier patch I made and it screwed up moving by character on the line. So...before I spent a lot of time debugging that, I thought I'd ask if we always wanted the EOL indicator in *flat review* or not. Obviously, I was in a hurry to end my day and forgot to add "flat review" in comment #6. Sorry about that!
(In reply to comment #8) > I see two main diffs: > > 1) All calls to braille.Text are surrounded by conditionals for whether or not > to pass in the EOL indicator or not. I'm not sure this is necessary since the > inside of braille.Text already has this conditional. Jon - were you seeing bad > behavior that made you add this extra code, or was it just my stupid comment > #6? sorry, i should have been more careful and looked at braille.Text does before putting in the conditionals. but now i am confused about comment #6. > 2) flat_review.py has a new conditional to pull out the EOL. I tried this in > an earlier patch I made and it screwed up moving by character on the line. > So...before I spent a lot of time debugging that, I thought I'd ask if we > always wanted the EOL indicator in *flat review* or not. I think if the user disables EOL, it should not just be in normal mode, but when flat reviewing too. sorry to hear that we are getting a flat review navigation bug.
Created attachment 114221 [details] [review] Patch that seems to work everywhere with everything...I hope. This seems to work well in focus tracking and flat review. It also regression tests well and pylints fine. It might be a keeper, but you never know. Please test!
Committed for 2.23.5. Marking as pending. Though we've kind of given this one some beating, I'd like a bit more confirmation that this is indeed the fix people are looking for.
all good, thanks Will
Thank you! Closing as FIXED. Thanks also to Mario!