Re: [orca-list] Strange speech problem



Le 14/01/2019 à 14:56, Joanmarie Diggs a écrit :
On 1/14/19 5:19 AM, Colomban Wendling wrote:
Le 10/01/2019 à 11:47, Samuel Thibault a écrit :
Alex ARNAUD, le jeu. 10 janv. 2019 11:42:25 +0100, a ecrit:
Should I need to report an issue against AT-SPI?

The X11 event contains the return keysym in that case so it's probably
at-spi or atk (or perhaps even gtk) which needs to be fixed, yes.

I'm not quite sure, the result we're seeing comes from Orca transforming
the event_string value in KeyboardEvent.__init__().  The original
event_string contains ASCII character 0x0D for Control+Return; but the
issue is that it's the same for Control+M.

I'm not sure what, if anything, should be "fixed", and I'm not sure how
(e.g. expected behavior).  Maybe Orca's transformation should take into
account the keyval to discriminate those cases?
Opinions?

The event_string we we get from AT-SPI2 should contain what we want to
present. Orca calculates the keyval_name largely as a fallback. Trying
to figure out which value is the right value is not ideal. It would be
great if you could fix this in AT-SPI2.

The thing is that AT-SPI2 is reporting exactly the X event: the
XLookupString is the same in both cases, and it's byte 0x0D (ASCII CR).
As Sam said, it's probably better to check the keyval information before
making this transformation.  Or even, maybe just use the keyval_name for
both in this case?  It would be fairly simple to do:

             value = ord(self.event_string[0])
             if value < 32:
-                self.event_string = chr(value + 0x40)
+                self.event_string = self.keyval_name

Maybe with a fallback in case keyval_name is empty, but well.  In any
case, it should fix this, and seems more robust than the current guess.

Apparently event.id is the keyval, so if it's not wanted to use the
keyval_name (which seems better IMO as it'd handle e.g. Return as well),
it would be possible to also check that event.id is an alphabetic
character or something before doing the conversion.

Regards,
Colomban


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]