Re: [orca-list] Orca and MuseScore



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> 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


--
Marc Sabatella
marc outsideshore com


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