Re: [orca-list] orca 3.11 and java applications

[José Vilmar Estácio de Souza <vilmar informal com br>]

Hi Joanie and all.

It seems I managed to get the menu bar to be read by orca, although I am 
not sure if done in the best way.

The problem now is that the menus are not read when I press down arrow.

KEYBOARDEVENT: type=<enum ATSPI_KEY_PRESSED_EVENT of type AtspiEventType>
                id=65364
                hw_code=116
                modifiers=0
                event_string=(Down)
                keyval_name=(Down)
                is_text=True
                timestamp=2185793020
                time=1385182672.183455
                keyType=navigation
                shouldEcho=False

----------> QUEUEING FOCUS:
DEQUEUED FOCUS:  <----------

vvvvv PROCESS OBJECT EVENT focus: vvvvv
OBJECT EVENT: focus:                                   detail=(0,0,0)
----------> QUEUEING OBJECT:STATE-CHANGED:FOCUSED
    app.name='GroovyConsole' name='New File' role='menu item' 
state='armed enabled opaque selectable selected sensitive showing 
visible' relations=''
Script for event: GroovyConsole 
(module=orca.scripts.toolkits.J2SE-access-bridge.script)
TOTAL PROCESSING TIME: 0.0054
^^^^^ PROCESS OBJECT EVENT focus: ^^^^^

DEQUEUED OBJECT:STATE-CHANGED:FOCUSED  <----------

vvvvv PROCESS OBJECT EVENT object:state-changed:focused vvvvv
OBJECT EVENT: object:state-changed:focused             detail=(1,0,0)
    app.name='GroovyConsole' name='New File' role='menu item' 
state='armed enabled opaque selectable selected sensitive showing 
visible' relations=''
Script for event: GroovyConsole 
(module=orca.scripts.toolkits.J2SE-access-bridge.script)
TOTAL PROCESSING TIME: 0.0023
^^^^^ PROCESS OBJECT EVENT object:state-changed:focused ^^^^^

In the default scripts inside function onFocusedChanged, we have the 
following code:

        obj = event.source
        state = obj.getState()
        if not state.contains(pyatspi.STATE_FOCUSED):
            return

Looking in the debug output of orca we have:
vvvvv PROCESS OBJECT EVENT object:state-changed:focused vvvvv
OBJECT EVENT: object:state-changed:focused             detail=(1,0,0)
    app.name='GroovyConsole' name='New File' role='menu item' 
state='armed enabled opaque selectable selected sensitive showing 
visible' relations=''
Script for event: GroovyConsole 
(module=orca.scripts.toolkits.J2SE-access-bridge.script)
TOTAL PROCESSING TIME: 0.0023
^^^^^ PROCESS OBJECT EVENT object:state-changed:focused ^^^^^

Since state does not contains pyatspi.STATE_FOCUSED, the process of this 
event is terminated without produce the expected result.

Am I correct?
Thanks.


On 11/21/2013 10:59 PM, Joanmarie Diggs wrote:
> Hey José.
>
> > there is the lack of a left parenthesis in
> > src/orca/scripts/toolkits/J2SE-access-bridge/script.py, at line 176.
>
> D'oh! Fixed pushed to master.
>
> > Now the problem is that the menu bar is not read by orca when I press
> > the f10 key.
>
> Okay, let's see what we've got to work with. To keep the verbiage down
> for ease of reading, I'm going to trim out a lot of the log output.
>
> > vvvvv PROCESS OBJECT EVENT focus: vvvvv
>
> We really want to ignore those focus: events if we can since they are
> going away.
>
> > vvvvv PROCESS OBJECT EVENT object:state-changed:selected vvvvv
>
> That selected event is for the File menu. That's one candidate. But
> let's see what else we've got....
>
> > vvvvv PROCESS OBJECT EVENT object:property-change:accessible-value vvvvv
>
> That value-change event is for the File menu. Insert a "huh?" here.
> Silly toolkit....
>
> > vvvvv PROCESS OBJECT EVENT object:state-changed:checked vvvvv
>
> And now the file menu claims to be checked. Super. Moving on....
>
> > vvvvv PROCESS OBJECT EVENT object:state-changed:focused vvvvv
> > OBJECT EVENT: object:state-changed:focused             detail=(1,0,0)
> >      app.name='GroovyConsole' name='File' role='menu' state='checked
> > enabled focusable selectable selected sensitive showing visible'
> > relations=''
> > Script for event: GroovyConsole
> > (module=orca.scripts.toolkits.J2SE-access-bridge.script)
> > script.skipObjectEvent: skipped due to more recent event of the same
> > type in a different object
> > ^^^^^ PROCESS OBJECT EVENT object:state-changed:focused ^^^^^
>
> The above event looks like the winner. However, you'll notice that even
> though it has detail1 == 1 (means it is claiming to have gained focus),
> it doesn't have state focused in the state set. That might be a bug.
> Then again, it might not, because the output indicates it was skipped
> because something else claimed focus after it. So the lack of state
> focused in the state set might not be a bug after all. Let's see what
> claimed focus....
>
> This next item:
>
> > vvvvv PROCESS OBJECT EVENT object:state-changed:focused vvvvv
> > OBJECT EVENT: object:state-changed:focused             detail=(0,0,0)
> >      app.name='GroovyConsole' name='None' role='push button'
> > state='enabled focusable opaque sensitive showing visible' relations=''
> > Script for event: GroovyConsole
> > (module=orca.scripts.toolkits.J2SE-access-bridge.script)
> > TOTAL PROCESSING TIME: 0.0042
> > ^^^^^ PROCESS OBJECT EVENT object:state-changed:focused ^^^^^
>
> Is an indication of a focus loss (detail1 == 0, plus it doesn't have
> state focused).
>
> And the winner is:
>
> > vvvvv PROCESS OBJECT EVENT object:state-changed:focused vvvvv
> > OBJECT EVENT: object:state-changed:focused             detail=(1,0,0)
> >      app.name='GroovyConsole' name='None' role='root pane' state='enabled
> > focusable focused opaque sensitive showing visible' relations=''
>
> That guy. A root pane is claiming focus. Fail. But we have no indication
> that it is not really focused from the above. As a result, we have to
> trust the toolkit.
>
> > SPEECH OUTPUT: 'root pane'
> > TOTAL PROCESSING TIME: 0.0324
> > ^^^^^ PROCESS OBJECT EVENT object:state-changed:focused ^^^^^
>
> Thus we present that root pane.
>
> I suspect that merely ignoring the root pane's focus claim in
> onFocusedChanged() will be insufficient because of skipObjectEvent()
> seeing the subsequent focus claim of the root pane. But you can try.
>
> If that fails as I expect it to, I don't think you'll want to modify or
> override skipObjectEvent() because that is one of our defenses for event
> floods. It needs to remain very light and performant.
>
> So what else can we do in the face of this bogus focus claim?
>
> If you look in that toolkit script, there are existing hacks in place
> related to popup menus and root panes. As sad as I am to make the
> following suggestion.... It would be interesting to see if the current
> hack for popup menus could be tweaked slightly to also apply to the
> menus on the menu bar.
>
> You up for giving that a try?
>
> > Thanks.
>
> Thank you!!
> --joanie

--
{}S José Vilmar Estácio de Souza