New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automatically switch braille tethering between review and focus #2385
Comments
Comment 1 by jteh on 2012-05-26 04:50 |
Comment 2 by aliminator (in reply to comment 1) on 2012-05-29 10:04 |
Comment 3 by jteh (in reply to comment 2) on 2012-05-30 00:35
This simply doesn't make sense. You can't be tethered to both focus and review at the same time. Otherwise, NVDA can't know which cursor you want it to show. They are very separate cursors, which is why they have separate commands.
Whether a user uses speech or not isn't relevant here. The experience is the same for speech users. They still have two separate cursors.
True, but braille users can use a keyboard just as well as speech users can. Perhaps this calls for more braille display key bindings. This needs to be done separately for each display and users of those displays need to make suggestions about this.
This is true for speech users as well. Speech users have to activate the object using NVDA+numpadEnter or route the focus to the object using NVDA+shift+numpadMinus. |
Comment 4 by jteh on 2012-05-30 00:37 |
Comment 5 by aliminator (in reply to comment 4) on 2012-05-31 11:14 |
Comment 6 by jteh (in reply to comment 5) on 2012-06-07 08:30
If you want to explore the screen in places the system focus can't go, you use review. This is true for both speech and braille users. Thus, tethering ot review makes sense.
I think your example is missing. :) |
Comment 7 by aliminator on 2012-06-13 15:27 |
Comment 8 by jteh on 2012-06-15 09:56 |
@jcsteh commented:
I think it is perfectly valid to switch back to focus as soon as the focus is explicitly changed by the user, with pressing tab for example. |
Agree.
…On Thu, May 11, 2017 at 4:14 AM, Leonard de Ruijter < ***@***.***> wrote:
@jcsteh <https://github.com/jcsteh> commented:
Perhaps you're asking for an option whereby braille can automatically
tether to review when object navigation commands are used. However, if we
do this, what will cause it to tether back to focus?
I think it is perfectly valid to switch back to focus as soon as the focus
is explicitly changed by the user, with pressing tab for example.
cc @dkager <https://github.com/dkager>, @bramd <https://github.com/bramd>,
@josephsl <https://github.com/josephsl>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2385 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AFGivWT8RUZyTGLBHsiqhDq76ge1Beahks5r4t9wgaJpZM4NXyjm>
.
--
Derek Riemer: Improving the world one byte at a time!
- University of Colorado Boulder Department of computer science, 4th
year undergraduate student.
- Accessibility enthusiast.
- Proud user of the NVDA screen reader.
- Open source enthusiast.
- Skier.
Personal website <http://derekriemer.com>
|
After looking at the code as well as some discussion with @jcsteh and @dkager, here are some rough implementation ideas:
|
Ok, this is causing major headaches. I've tried two things so far.
Whatever we do, there's some discussion required about the how and the why. |
To make clear, I myself prefer the second approach. @dkager, you? |
Yes, I prefer option 2 even if it takes some refactoring. |
One question that I possiblely didn't understood...
You wrote:
In other words, the braille will first present the focus object in review
mode and then auto tethers to focus.
The only difference will not be the cursor shape?
Rui
…-----Mensagem Original-----
De: Leonard de Ruijter
Data: 13 de julho de 2017 07:18
Para: nvaccess/nvda
Cc: Subscribed
Assunto: Re: [nvaccess/nvda] Automatically switch braille tethering between
review and focus (#2385)
Ok, this is causing major headaches. I've tried two things so far.
The implementation as proposed above. Auto tethering to focus is done using
Braillehandler.handleGainFocus and Braillehandler.handleReviewMove. Auto
tethering to review is done using the several scripts in globalCommands.
This has the drawback that, if you are auto tethered to review and you
change focus, the review cursor changes before the focus is handled. In
other words, the braille will first present the focus object in review mode
and then auto tethers to focus.
After some discussion with @dkager, we decided that using the scripts for
this might not be the nicest way to do. To keep things in sync nicely, auto
tethering shouhld be done by handleReviewMove instead. However, this has the
following implications:
A. handleReviewMove should not auto tether when the move is caused due to
the review cursor following the focus or the caret. Since most of the review
following focus is done using api.setNavigatorObject with the isFocus
parameter set to True, api.setNavigatorObject should somehow communicate
this to handleReviewMove. However, setNavigatorObject doesn't execute
handleReviewMove itself, but executes the becomeNavigatorObject event, which
executes handleReviewMove. The isFocus parameter gets lost in this process.
This can be fixed by creating a caching variable, e.g.
eventHandler.lastReviewMoveDueToFollowing. This new variable should also be
set properly by api.setReviewPosition based on a new parameter isCaret. At
least for setNavigatorObject, I'd rather pass this info as an event
parameter, but that means we break backwards compatibility. Side note, this
is why I belief add-ons should implement events like
def event_becomeNavigatorObject(self, obj, **kwargs):
B. When going for point A, there are some edge cases that need to be changed
in setting the navigatorObject. For example, in the explorer appmodule on
the SuggestionListItem class, the navigator object is set for
event_UIA_elementSelected. This call of setNavigatorObject would need the
extra isFocus parameter. Honestly, it turns out that this code isn't doing
what it should do anyway, since event_UIA_elementSelected turns out to be a
sort of focus event which shouldn't make the navigator object follow if
reviewFollowFocus is off. CC @michaelDCurran
Whatever we do, there's some discussion required about the how and the why.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
@leonardder commented on 13 Jul 2017, 16:18 GMT+10:
We could consider making eventHandler use the new extensionPoints.callWithSupportedKwargs function I added in #7484, which would allow us to pass additional kwargs without breaking backwards compat:
|
@jcsteh commented on 16 aug. 2017 13:49 CEST:
That would be awesome, I think. Does this fit in the scope of #7484? |
Hi, I’m thinking yes, as it then allows add-ons to perform interesting work (I myself can use this for event tracking code in some of my add-ons). But I think it’d be best to wait until September when extension points become stable unless this can be done a bit early. Thanks.
From: Leonard de Ruijter [mailto:notifications@github.com]
Sent: Wednesday, August 16, 2017 5:32 AM
To: nvaccess/nvda <nvda@noreply.github.com>
Cc: Joseph Lee <joseph.lee22590@gmail.com>; Mention <mention@noreply.github.com>
Subject: Re: [nvaccess/nvda] Automatically switch braille tethering between review and focus (#2385)
<https://github.com/jcsteh> @jcsteh commented on 16 aug. 2017 13:49 CEST <#2385 (comment)> :
We could consider making eventHandler use the new extensionPoints.callWithSupportedKwargs function I added in #7484 <#7484> , which would allow us to pass additional kwargs without breaking backwards compat:
That would be awesome, I think. Does this fit in the scope of #7484 <#7484> ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#2385 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AHgLkEFJB6InVjaigwlF-qlH6rPoob66ks5sYuFMgaJpZM4NXyjm> .
|
I think this should be done separately from #7484, just because it's
slightly unrelated.
|
There has been some discussion going in #7484 about using extensionPoints.callWithSupportedKwargs in eventHandler. This would be great in situations where we want to add an additional argument to a well established event, such as becomeNavigatorobject. However, there is a problem that some parts in the code call positional arguments as if they were kwargs, and vise versa. This is why I propose callWithSupportedKwargs as a fallback for cases where the event handler tries to call a function with too many arguments. |
Reported by aliminator on 2012-05-25 12:32
When a braille display is tethered to focus and object navigation is used it does not refresh properly.
E.g. Notepad is used with some text entered. The text still shows up when navigating to another application using object navigation.
Nevertheless, this works as expected when the braille display is tethered to review.
The text was updated successfully, but these errors were encountered: