Re: [orca-list] Strange speech problem

[Samuel Thibault <sthibault hypra fr>]

Samuel Thibault, le ven. 15 févr. 2019 11:00:34 +0100, a ecrit:
> Hello,
>
> Colomban Wendling, le lun. 14 janv. 2019 15:29:33 +0100, a ecrit:
> > 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
>
> Looking at this again due to something else. I
> can't reproduce the initial issue reported on
> https://mail.gnome.org/archives/orca-list/2018-November/msg00113.html
> on my Buster box: when pressing control-enter, I am getting "Return"
> in the event_string field of the event provided by atspi, i.e. AT-SPI
> behaves correctly and orca's work around above is not triggered.

Ah, running this again in my normal desktop session, I get the same
issue, I'll dig a bit.

Samuel