-
-
Notifications
You must be signed in to change notification settings - Fork 634
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
Panning braille past the visible text in Scintilla doesn't update the braille display #5678
Comments
This suggests we aren't getting caret events for some reason. Perhaps we
aren't calling something we're meant to call. We're using the
SCI_GOTOPOS message to move the caret; see _setCaretOffset in
NVDAObjects.window.scintilla.ScintillaTextInfo. (You'll probably also
have ot take a look at the Scintilla API.) Maybe we have to scroll it first?
|
I suppose visually the caret doesn't move. It stays at the same place but text is scrolled up by one line. Then it's curious that using the arrow keys works as expected. I'll have a look at the Scintilla API. |
It seems that NVDA is not catching a caret update. For example, when you press the braille display's routing buttons on a line of text the braille cursor doesn't update until the next blinking cycle. Or rather, the blinking cycle isn't reset just after a routing button is pressed. This does happen if you press the arrow keys instead. I found that sending |
Also reproduced in SciTE, so updated the issue title to be more generic. |
Cintilla bug maybe? On 1/15/2016 9:21 AM, Davy Kager wrote:
Websites: email me at [email protected] mailto:[email protected] |
That is possible. Or maybe a feature: the rationale could be that if you programmatically change the caret position you might not need a subsequent notification that the caret moved. From: derekriemer [mailto:[email protected]] Cintilla bug maybe? On 1/15/2016 9:21 AM, Davy Kager wrote:
Derek Riemer
Websites: email me at [email protected] mailto:[email protected] mailto:[email protected] — |
If we're missing a caret update, most likely, a caret event wasn't fired. Because Scintilla uses the standard caret (at least, I think it does), this makes me wonder whether the caret is actually moving visually when you move it using braille. It'd be great if we can have someone with working eyeballs check this.
|
I believe Scintilla also uses another caret, maybe even an invisible one, to support assistive technology. To this end it sometimes explicitly updates it, including after you press the down arrow (SCI_LINEDOWN). On the other hand the API docs for SCI_GOTOPOS clearly state that the view is scrolled to make the caret visible. I’ll do some more testing… From: James Teh [mailto:[email protected]] If we're missing a caret update, most likely, a caret event wasn't fired. Because Scintilla uses the standard caret (at least, I think it does), this makes me wonder whether the caret is actually moving visually when you move it using braille. It'd be great if we can have someone with working eyeballs check this. — |
Looking at Scintilla's code and running some tests it appears that the system caret is updated very frequently (upon every blink I suppose). Another, possibly related issue is that sometimes when you press a cursor routing button NVDA moves the caret to the wrong position on a totally different line. By looking at NVDAObjects\window\scintilla.py the cursor routing buttons always use actual offsets into the text, not some kind of position guessing based on x-y coordinates. Could it be that both issues can be blamed on this one function |
Oh. Now I'm wondering whether perhaps the caret doesn't actually move at all as far as its screen location is concerned. Perhaps the new line scrolled on to the screen is at the same position as the old line, so the caret is actually in the same place. Perhaps Scintilla just redraws the text when it scrolls and doesn't have to "move" the caret in this case. That would mean we wouldn't get a locationChange event for the caret (which NVDA translates into a caret event). That doesn't explain why pressing down arrow works, though. Maybe down arrow scrolls more than one line when it hits the bottom but SCI_GOTOPOS doesn't? I think we need some sighted help here.
That one doesn't make sense. Was the right line displayed in the first place? Perhaps it wasn't, in which case it's probably a missing caret event.
I don't understand what you mean here. Using offsets is definitely the correct way to do things. Using coordinates will cause problems if the screen scrolls visually or the like without moving the caret. It's also far less reliable; mapping characters to screen coordinates and vice versa is an ugly, sometimes asymmetric business. |
As far as SuperNova and its screen scraping can tell me pressing down arrow also scrolls single lines, although I suppose it could be scrolling partial lines.
Exactly. So pressing cursor routing buttons should always be accurate but for some reason it isn't. |
Small update: just added some debugging code. There is only one place where the Win32 API function |
We use MSAA caret events. I'm pretty sure these relate to SetCaretPos, etc., but I don't know exactly what calls map to what events. My commment about the same location not firing an event was a guess.
That said, does SCI_GOTOPOS definitely result in SetCaretPos getting called? I'm wondering whether it doesn't get called at all since the caret doesn't actually move.
|
Based on my current Notepad++ settings:
Not sure if this is the issue. Maybe Scintilla sends a redraw or other GUI update when using the arrow keys but not when using Two possible issues:
|
At this point, I think it's going to be simpler to just fake a caret
event (eventHandler.executeEvent("caret", self)) in
ScintillaTextInfo._setCaretPos.
|
Judging by the following traceback this event should be fired by the Scintilla object, not its TextInfo. I haven't tried this yet.
|
Uh, so now I tried because it was super easy and I didn't know. This solution appears to work well and braille is much more responsive now. When you route the cursor with the routing buttons the move is immediately visible instead of having to wait till the next braille cursor blink. So naturally I am happy. Not going to do a PR since solution is but a single line, as per James: I also found a way to reproduce the 'routing to the wrong offset' issue:
Worth its own ticket you think? |
I think I raised this. It has to do with the fact that double tap of On 1/25/2016 1:13 PM, Davy Kager wrote:
Websites: email me at [email protected] mailto:[email protected] |
Ah, that would explain things. For the record, I do only click once, but indeed in a place where the cursor already was. From: derekriemer [mailto:[email protected]] I think I raised this. It has to do with the fact that double tap of On 1/25/2016 1:13 PM, Davy Kager wrote:
Derek Riemer
Websites: email me at [email protected] mailto:[email protected] mailto:[email protected] — |
Oh, yeah. That's #4703. |
So the routing buttons moving to an unexpected place is clearly another issue. Do you feel the fix for this panning issue should be added to the 'official' app module? It's a work-around, but probably faster than bringing this up with the Scintilla developer. Especially since if it is fixed upstream it then also has to cascade to third-party applications like Notepad++. If this kind of hack doesn't belong in NVDA I'll bake my own app module. :) |
I'm happy to add this hack to ScintillaTextInfo. I already set the
milestone to 2016.2.
|
…correctly when moving the cursor using a braille display. Fixes #5678.
Incubated in 07b2c92. |
Steps to reproduce:
script_braille_nextLine
or repeatedscript_braille_scrollForward
.To fix this, arrow up/down once. To work around the issue use the arrow keys to move through text, this behaves as expected. This does not happen in Notepad or WordPad. Tried with a portable copy of Notepad++ to make sure it isn't caused by a local configuration change. I haven't looked much further but will do that if this doesn't fall into the cantfix category.
The text was updated successfully, but these errors were encountered: