Added option "Enable Braille message timeout"

[surfer0627]

In NVDA_JP (language settings), there is an option called "Enable Braille message timeout".
Here is a short description from NVDAJP Release Notes 2016.1jp:

5.2.11. Enable Braille message timeout
This option allows disabling Braille message timeout. If this option is turned off, Braille message is displayed almost forever (10000sec).

[josephsl]

Hi, @nishimotz: can we work on a way to pull in your team’s diffs if this feature is accepted? Thanks.

From: surfer0627 [mailto:notifications@github.com]
Sent: Tuesday, April 12, 2016 9:13 PM
To: nvaccess/nvda nvda@noreply.github.com
Subject: [nvaccess/nvda] Added option "Enable Braille message timeout" (#5882)

In NVDA_JP (language settings), there is an option called "Enable Braille message timeout".
Here is a short description from NVDAJP Release Notes 2016.1jp: https://www.nvda.jp/nvda2016.1jp/en/readmejp.html

5.2.11. Enable Braille message timeout
This option allows disabling Braille message timeout. If this option is turned off, Braille message is displayed almost forever (10000sec).

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub #5882

[jcsteh]

If it really does just set a long timeout, why wouldn't a user just enter a long timeout (rather than having a separate option)?

If there is a good use case for having a true "forever" setting, I think we can do far better in terms of UX. I think "Disable message timeout" isn't going to make sense to many users.
I'd suggest a group of radio buttons labelled "Display messages:":

1. "Disabled": Disables messages.
2. "For (sec):": Enables a text box where you can enter the time, just as we have now.
3. "Until dismissed": Shows the message until it is manually dismissed by the user.

[nishimotz]

The 'forever' setting is necessary for input composition and/or character descriptions.
For ideographic characters used in Japanese or Chinese, character descriptions are usually displayed as ui.message, rather than as an object's property.
It is somewhat depending on our work around braille support of the input composition.
Braille display users want to treat such character descriptions as the properties of the text objects, rather than the volatile messages.

I wanted to make the setting file of NVDAJP compatible with the original version.
That was the reason we added "Enable (disable) Braille message timeout" option.

Actually I don't like the solution so far, because I understand ui.message should be volatile.
I am happy to discuss the use cases and find better solutions.

[jcsteh]

From what I can see, NVDAObjects.behaviors.CandidateItem uses properties to present candidates, not ui.message. Is there somewhere else in our code that uses ui.message for candidates or is this NVDAJP code? If NVDAJP code, is there any reason you're not using (or at least deriving from) the input composition support in NVDA core, including the CandidateItem behaviour? CC @michaelDCurran.

[nishimotz]

For example, NVDAHelper.handleInputCandidateListUpdate uses ui.message for candidate items list.
The autoReportAllCandidates option, however, is not suitable for Japanese language.
For original NVDA, the same option is requested, so I hope @surfer0627 gives information regarding other language than Japanese.

[jcsteh]

Ah. I see ui.message is used there, but that's only to report all the candidates initially to give the user an overview of the candidates. I don't follow why you'd want that to stay on the display forever, though, since you have to navigate to a candidate before you can select it. Also, why is autoReportAllCandidates unsuitable for Japanese?

[surfer0627]

@jcsteh

If it really does just set a long timeout, why wouldn't a user just enter a long timeout (rather than having a separate option)?

Now, the maximum message timeout is "20" seconds. Sometimes, it's not enough for users press numpad2 twice to read "character descriptions".
If message timeout could be extended to 10000sec, then it matches the request.

The reason why I request to add an option, because this feature is based on code from NVDA_JP. It sounds like a time-saving solution.

[nishimotz]

Regarding input composition, another point is
NVDAObjects.IAccessible.mscandui.reportSelectedCandidate.

I have reviewed past discussion in Japanese community and learned as follows:

• Novice user of braille display may have difficulty with input composition sessions if the character descriptions are suddenly changed to the document content while the user is still verifying the candidates
• Other than input compositions, it may be useful if the braille message is not dismissed after the absence from computer for a while. For example, the user fetches incoming mails. If it takes time, the user may go to restroom during that. Message such as 'you have 10 mails' should not dismissed until the user returns. (Actually I don't know what e-mail software was being discussed at that time)

@surfer0627
Are you using NVDAJP already?
So far, NVDA does not support braille display regarding review_currentCharacter.
NVDAJP uses braille.handler.message to show character descriptions, as well as speech.

[jcsteh]

I don't think the argument for messages while away from the computer justifies this, as even for sighted users, most pop-up style notifications like this disappear after a while. If the notification was intended to stay there the entire time, a modal dialog should have been used.

[nishimotz]

I was requested to make a patch or 'ready to pull' version of my work, however, I would like to discuss further, before Chinese language community will make a try-build.

Back to "very long Braille message timeout," just allowing a long timeout seemed nicer, in terms of user experience, as @jcsteh mentioned.

As I wrote previously, the reason of my design was compatibility of nvda.ini file.

The Braille.messageTimeout is defined as follows:

    messageTimeout = integer(default=4,min=0,max=20)

If forked version of NVDA allows the bigger values for this parameter, the modified nvda.ini would raise validation error with the original or previous version of NVDA.

For example opening Braille settings dialog causes error as follows and the dialog cannot be accessed:

ERROR - unhandled exception (16:51:24):
Traceback (most recent call last):
  File "gui\__init__.pyo", line 234, in onBrailleCommand
  File "gui\__init__.pyo", line 192, in _popupSettingsDialog
  File "gui\settingsDialogs.pyo", line 75, in __init__
  File "gui\settingsDialogs.pyo", line 1494, in makeSettings
  File "config\__init__.pyo", line 972, in __getitem__
  File "config\__init__.pyo", line 1027, in _cacheLeaf
  File "validate.pyo", line 602, in check
  File "validate.pyo", line 634, in _check_value
  File "validate.pyo", line 822, in is_integer
VdtValueTooBigError: the value "10000" is too big.

The user profiles of NVDA may be shared with various versions of NVDA, so it would be seriously inconvenient.

We cannot change the behaviors of past versions regarding this, so I thought that adding new option is safe way of doing this.

Comments are welcome.

[nishimotz]

We already treats the value of zero as special.
"Specifying 0 disables displaying of these messages completely."

If we define "Specifying 20 makes Braille message displayed forever," it won't break the profile compatibility across NVDA versions.

After this change, the maximum number of the timeout will be 19 seconds.
I wonder how the users will be inconvenient, who really want this timeout to be exactly 20 seconds.

[derekriemer]

What about -1?

On 8/9/2016 5:30 PM, Takuya Nishimoto wrote:

We already treats the value of zero as special.
"Specifying 0 disables displaying of these messages completely."

If we define "Specifying 20 makes Braille message displayed forever,"
it won't break the profile compatibility across NVDA versions.

After this change, the maximum number of the timeout will be 19 seconds.
I wonder how the users will be inconvenient, who really want this
timeout to be exactly 20 seconds.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#5882 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFGivVUoQhdXeGCqduI2tUFtPHN7mxlkks5qeQ2DgaJpZM4IGCHy.

---

Derek Riemer

• Department of computer science, third year undergraduate student.
• Proud user of the NVDA screen reader.
• Open source enthusiast.
• Member of Bridge Cu
• Avid skiier.

Websites:
Honors portfolio http://derekriemer.com
Awesome little hand built weather app!
http://django.derekriemer.com/weather/

email me at derek.riemer@colorado.edu mailto:derek.riemer@colorado.edu
Phone: (303) 906-2194

[surfer0627]

I'm going to close this. It was covered by #6777.