Hi,

Thanks for going forward with this!
The key presses and releases are something that Qt does and I can investigate.
I have several problems with it - it makes applications react to key presses 
slower than they should for example.

The other issue is presumably inside the Kate (ktexteditor framework) code.

I will focus on KWin for now, I hope I will have something to test this 
weekend.

Cheers,
Frederik


On torsdag 1. november 2018 13:49:26 CET chrys wrote:
> Howdy list,
> 
> Joanie investigated the Kate issues for us. ill forward the results here.
> 
> maybe we can see what we can do.
> 
> cheers chrys
> 
> 
> 
> -------- Weitergeleitete Nachricht --------
> Betreff: 	Re: [orca-list] Kate editor accessibility
> Datum: 	Thu, 1 Nov 2018 12:35:22 +0100
> Von: 	Joanmarie Diggs <jdiggs@igalia.com>
> An: 	chrys <chrys@linux-a11y.org>
> Kopie (CC): 	orca-list <orca-list@gnome.org>
> 
> 
> 
> Hey Chrys.
> 
> In answer to your questions:
> 
> On 10/31/18 11:02 PM, chrys wrote:
> > Bug 1: Arrow up/ down will not interrupt orcas current speech output.
> > maybe it looks like to additional content to orca instead of an line
> > navigation. So ctrl needs to been pressed after every line change to
> > interrupt speech. can you check why orca is not interrupting here on
> > line change.
> 
> When you use the arrow keys to move by line, Orca asks AT-SPI2 for the
> line at offset. When I ask for a line of text, Kate responds with all
> the text typed until I pressed Enter (i.e. a hard return) What Kate
> should instead respond with is all the text on the visual line, which
> ends at the point the text wrapped due to the window size. Make sense?
> 
> > Bug 2. After doing arrow up / down start to navigate by char (arrow left
> > / right) orca does repeat the previous line once instead of just speak
> > the char. this only happen once and directly after an line navigation
> > (arrow up/ down).
> 
> It looks like Kate is not telling us about key presses and key releases;
> only key releases. What we see from Gtk+, Gecko, etc. is an ordering
> like this:
> 
> Action 1:
> Key press down
> Caret moves one line down
> Key release down
> 
> Action 2:
> Key press right
> Caret move one char to the right
> Key release right
> 
> Action 3:
> Key press right
> Caret move one char to the right
> Key release right
> 
> What we're getting from Kate seems to be:
> 
> Action 1:
> Caret moves one line down
> Key release down
> 
> Action 2:
> Caret move one char to the right
> Key release right
> 
> Action 3:
> Caret move one char to the right
> Key release right
> 
> Orca uses a combination of the caret-moved events and the keyboard
> events to try to figure out what the user is doing and, based on that,
> figure out what to present. This combination is needed because a
> keyboard event doesn't necessarily result in the caret moving, and
> caret-moved events don't tell you why the move occurred; merely that the
> caret is at a new location.
> 
> So when a caret moved event comes in, Orca looks at the last key event
> and determines what to present to you. In the Gtk+, Gecko, etc.
> scenario, we know what arrow key you pressed before the caret moves so
> we can guess correctly whether or not to present a line versus a
> character. But Kate isn't telling us about key presses. So the last key
> isn't what you just did; it's what you did one step back. It's only
> after Orca presents the new caret's location that it is told what arrow
> key you pressed.
> 
> There may be some sort of hack I can add in Orca to work around this
> issue. But the lack of key press events is a bug in Kate (or Qt or
> whatever). And if they fix that bug, I believe Orca will start doing the
> right thing automatically. Plus the more hacky guesswork I have to add
> to Orca, the less reliable Orca will be. So do you think you can get
> this fixed in Kate (or Qt or whatever)?
> 
> --joanie