Re: [orca-list] Orca and MuseScore

[Joanmarie Diggs <jdiggs igalia com>]

Hey Marc.

Thanks for the update, and nice job sorting it all out! You can attach 
your script to a new bug you file against Orca in 
https://gitlab.gnome.org/GNOME/orca.

Take care.
--joanie

On 1/20/20 11:25 PM, Marc Sabatella wrote:
> I accidentally replied off-list to Joanmarie, but also I've made more 
> progress today, so rather than copy my original response here to the 
> list, I'm updating based on my current status
>
> Based on the suggestion to hunt through the debug logs for clues as to 
> why the response is so slow (well, a second or so is very slow compared 
> to NVDA), I went ahead and did that, and sure enough, discovered the 
> cause.  When I issue a navigation command in MuseScore that triggers an 
> event to read, we also update a couple of dozen other widgets (various 
> properties of the selected score element in an "Inspector" window).  
> When Orca receives the value change event, it queues it up immediately, 
> but it has to wait in line behind all the other events being generated 
> by the other elements.  These are predefined Qt widgets, so we're not 
> really in charge of generating the events for them.  Orca doesn't 
> actually read anything for these because none of them have focus, but 
> updating those couple of dozen widgets generates hundreds of events, 
> and I guess it takes time to process them all just to determine that 
> nothing should be read.
>
> Probably there is some optimization to be made within Qt or in how we 
> update those widgets.  Like, somehow suppressing generation of the 
> events if the Inspector does not have focus.  But for now, I have solved 
> the problem for myself by just making sure we don't update the Inspector 
> at all if its window is not visible.  With that change, if I hide the 
> Inspector window, everything is lightning fast.  Good enough for now.
>
> Related issue - I was having Orca read using speakMessage, with the 
> interrupt parameter set to true, but it wasn't actually interrupting.  
> So So even though Orca responds to a single cursor key quickly, if you 
> press the cursor key several times in quick succession to navigate 
> through the score, Orca reading the whole description for each element 
> before moving on to the next, so it gets way behind.  I discovered that 
> if I switched to calling presentationInterrupt explicitly, and then 
> using presentMessage for the message, it interrupts as I want.  Meaning 
> as soon as I press the cursor key a second time, it stops reading the 
> first element and starts reading the second.  It seems like maybe a bug 
> in Orca that interrupt parameter to speakMessage doesn't have this same 
> effect.  I followed that through the Orca source several levels deep but 
> didn't see anything obvious to explain it.
>
> Anyhow, I am at this point completely happy with the results I am 
> getting, so thanks for the feedback!
>
> It does still bother me philosophically, though, that I am having to 
> resort to what feels like a bit of a hack in relying on value change 
> events for something that doesn't really have a value in the usual 
> sense.  BTW, while value might normally be numeric according to the 
> value interface, MSAA and UIA at least do say that text elements should 
> return their content as value, which is how we started on that path I 
> think.  Still, given the actual definitions from IA2 etc, my feeling is 
> calling it an image with a changing description is still the best fit, 
> and I wish I could convince Orca to respond.  I did try installing my 
> own listening for object:property-change:accessible-description (which 
> is what Accerciser shows is being generated) but it never fires, and the 
> debug log leads me to suspect it is never even seen by Orca - the string 
> just doesn't appear in the log at all.  So I feel like pyatspi is 
> probably filtering it out for some reason.
>
> Samuel has an interesting idea of implementing our score widget as a 
> Document, with individual elements within it that are selected via 
> navigation.  That makes a ton of sense, and we have had thoughts along 
> those lines ourselves as well.  Maybe someday we'll look at that, but 
> it's a pretty big change to contemplate.  Right now I'm happy just to 
> have it working!
>
> BTW, the changes I've made to MuseScore to support what I'm doing here 
> are not extensive but probably won't be part of MuseScore for a little 
> while yet.  We're releasing 3.4 imminently, maybe this will go into 
> 3.4.1, or maybe not until a later release.  When it happens, though, I 
> definitely do want to share my script for including in Orca.  What's the 
> process for that?
>
> Marc
>
> On Sun, Jan 19, 2020 at 7:29 PM Marc Sabatella <marc outsideshore com 
> <mailto:marc outsideshore com>> wrote:
>
>     Hello!  I am one of the developers of MuseScore, and I've been
>     working on accessibility on and off the last few years.  My spam
>     folder and I had a disagreement about my subscribing to this list
>     (!), so I wasn't able to participate in the recent discussion, but I
>     learned a lot from reading the exchanges.  Also from discussions on
>     the Qt list and with some JAWS scripters.  Bottom line, I've managed
>     to get MuseScore working with Orca, but I do still have some questions.
>
>     What I was having trouble with is getting Orca to read changes to a
>     custom Qt widget representing a musical score.  The changes
>     represent the currently-selected note or symbol, so it changes on
>     cursor navigation.  After a ton of trial and error - different roles
>     for the widget, different properties for the info I wanted read,
>     different events to triggers the reading - I came up with something
>     that works, using a short Orca script.  But Orca responds more
>     slowly than I expect (more slowly than NVDA or JAWS on Windows), and
>     I'm not sure why, so I'd appreciate any suggestions.
>
>     What I have right now is a role of image for my widget, although
>     others work too.  The name is the name of the score.  The value and
>     description are both set to the text I want read - a verbal
>     description of the selected score element.  I send a value change
>     event the selection changes, because try as I might, I just can't
>     seem to get Orca to recognize a description change event.  Orca
>     doesn't read anything on receipt of the value change event by
>     default, but my script listens for this event and reads the
>     description (not the value, because that always comes out as numeric 0).
>
>     As I said, it works, but there is a pretty big lag - like a second
>     or more - between when I send the event from MuseScore and when Orca
>     reads the result.  Accerciser sees the event immediately, so I know
>     the delay is not on the MuseScore side.  What's weird is, spinboxes
>     go through my same onValueChanged handler, and it reads instantly. 
>     Somehow my custom widget takes much longer to get there.
>
>     As I mentioned, I'd really rather use a description changed event,
>     but even though I'm installing a listener for
>     object.property-change.accessible-description, it never fires. 
>     Probably I'm doing it wrong, but it seems like the right syntax. 
>     Running debug info on Orca, though, it doesn't seem the event gets
>     received (but again, Accerciser sees it just fine).
>
>     So, my questions at this point:
>
>     1) why Orca is so slow to read this?
>     2) anything special I need to do to get accessible-description events?
>     3) any other ideas for ways of eliminating the need for the script
>
>     BTW, there was a question about the "filler" objects in the tree. 
>     These are widget layout elements used by Qt - to control whether
>     controls are laid out horizontally or vertically or in a grid, and
>     not meant to be directly accessible at all.  Not sure why Qt puts
>     them in the accessible object hierarchy.
>
>     -- 
>     Marc Sabatella
>     marc outsideshore com <mailto:marc outsideshore com>
>
>
>
> --
> Marc Sabatella
> marc outsideshore com <mailto:marc outsideshore com>
>
> _______________________________________________
> orca-list mailing list
> orca-list gnome org
> https://mail.gnome.org/mailman/listinfo/orca-list
> Orca wiki: https://wiki.gnome.org/Projects/Orca
> Orca documentation: https://help.gnome.org/users/orca/stable/
> GNOME Universal Access guide: https://help.gnome.org/users/gnome-help/stable/a11y.html