After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 494651 - [pyatspi] Orca's OBJECT EVENT debug routine not outputting all information for "object:selection-changed" menu bar event
[pyatspi] Orca's OBJECT EVENT debug routine not outputting all information fo...
Status: RESOLVED FIXED
Product: orca
Classification: Applications
Component: general
2.21.x
Other Linux
: Normal normal
: 2.22.0
Assigned To: Rich Burridge
Orca Maintainers
Depends on:
Blocks: 448848
 
 
Reported: 2007-11-07 16:18 UTC by Rich Burridge
Modified: 2008-07-22 19:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to fix the problem. (4.32 KB, patch)
2007-11-09 16:43 UTC, Rich Burridge
accepted-commit_now Details | Review

Description Rich Burridge 2007-11-07 16:18:08 UTC
Old Orca:

OBJECT EVENT: object:selection-changed                 detail=(0,0)
             app.name='soffice'            name=None role='menu bar' state='ENABLED FOCUSABLE OPAQUE SENSITIVE SHOWING VISIBLE' relations=''


New Orca:

OBJECT EVENT: object:selection-changed                 detail=(0,0)
             [menu bar | ]

The missing information is very useful for debugging purposes.
Comment 1 Willie Walker 2007-11-07 16:39:31 UTC
I'm getting the "Old Orca" behavior with the sources from trunk.  To be sure, I even modified my debug.py:getAccessibleDetails method to say "myapp.name=" instead of "app.name" and it is indeed what is being used.  Is it possible you might be picking up something somewhere else in your PATH or PYTHONPATH by accident?  

Alternatively, bug #491417 included a change for PATH and PYTHONPATH -- I wonder if that might be impacting you somehow?
Comment 2 Rich Burridge 2007-11-07 17:14:50 UTC
Yes, I'm seeing the old behaviour for a lot of the events, but just not
all of them. The cut&paste in the description above was from latest SV
trunk this morning.

Perhaps the question is why doesn't this event for the menu bar show all
this information?

Comment 3 Rich Burridge 2007-11-07 17:43:22 UTC
Adjusting summary to better reflect the problem I'm seeing.
note there may be other events/roles that exhibit a similar
behavior.
Comment 4 Willie Walker 2007-11-09 15:12:02 UTC
The signature of debug.py:printObjectEvent is this:

def printObjectEvent(level, event, sourceInfo=None):
    """Prints out an Python Event object.  The given level may be
    overridden if the eventDebugLevel is greater.  Furthermore, only
    events with event types matching the eventDebugFilter regular
    expression will be printed.

    Arguments:
    - level: the accepted debug level
    - event: the Python Event to print
    - sourceInfo: additional string to print out

A typical call is in focus_tracking_presenter.py:_processObjectEvent:

    debug.printObjectEvent(debug.LEVEL_FINEST, event)

Since no sourceInfo is provided, this results in just the "OBJECT EVENT:" line being output (we probably can get rid of the extra whitespace -- it was originally added to help align columns in a large listing, but I think that it makes things worse than better):

OBJECT EVENT: object:selection-changed                 detail=(0,0)

I believe the reason we aren't outputting event source information by default was to reduce some overhead in processing events.  So, we see this later on in focus_tracking_presenter.py:_processObjectEvent:

    debug.printDetails(debug.LEVEL_FINEST, "    ", event.source)

This is what results in this output (again, the extra whitespace probably can be removed):

             app.name='soffice'            name=None role='menu bar'
state='ENABLED FOCUSABLE OPAQUE SENSITIVE SHOWING VISIBLE' relations=''

As such, the output from focus_tracking_presenter.py:_processObjectEvent should be sufficient.  However, I see the following scripts call printObjectEvent and also pass in the event.source as the string for sourceInfo (one call in gedit.py even goes as far to str(event.source)):

src/orca/scripts/Evolution.py
src/orca/scripts/StarOffice.py
src/orca/scripts/gedit.py
src/orca/scripts/gnome-search-tool.py
src/orca/scripts/liferea.py
src/orca/scripts/nautilus.py

My guess is that the calls to printObjectEvent in these scripts is what is causing the confusion.  To confirm this, I just ran OOo and looked at the events.  Here's a snippet:

OBJECT EVENT: object:selection-changed                 detail=(0,0)
    app.name='soffice' name='File' role='menu' state='enabled focusable opaque s
electable selected sensitive showing visible' relations=''
OBJECT EVENT: object:selection-changed                 detail=(0,0)
             [menu | File]

What we're seeing is two outputs for the same object event.  The first portion comes from focus_tracking_presenter.py and the second comes from the script.  I think the calls to printObjectEvent in the script are redundant and should be removed.  Rich, what do you think?
Comment 5 Rich Burridge 2007-11-09 15:58:45 UTC
Phew! I *think* I understood all of that, but let me try to put it
another way, to make sure we are on the same page.

In old pre-pyatspi Orca, there was a toString() method in the Accessible
class (around line 1442), that would give us this information.

In the new pyatspi Orca, there is no equivalent.

I use to find being able to print this out from the various classes in
the script quite useful. I don't consider it redundant, because the 
information is right next to the other debug associated with the methods 
in the script class. I don't have to go looking back up the (some quite
voluminous) debug file.

Comment 6 Willie Walker 2007-11-09 16:19:44 UTC
> In old pre-pyatspi Orca, there was a toString() method in the Accessible
> class (around line 1442), that would give us this information.

Correct.  It looks like the calls in the scripts were doing this:

        debug.printObjectEvent(self.debugLevel,
                               event,
                               event.source.toString())

The calls were changed to this as part of the pyatspi migration:

        debug.printObjectEvent(self.debugLevel,
                               event,
                               event.source)

> In the new pyatspi Orca, there is no equivalent.

There is a getAccessibleDetails convenience method in debug.py that gives the extended information about accessible.  So, maybe the calls to printObjectEvent from the scripts should do this:

        debug.printObjectEvent(self.debugLevel,
                               event,
                               debug.getAccessibleDetails(event.source))

> in the script class. I don't have to go looking back up the (some quite
> voluminous) debug file.

It looks as though the output is going to show up in close proximity to the identical output from focus_tracking_presenter.py.  So, we'll end up with the following output:

vvvvv PROCESS OBJECT EVENT %s vvvvv
[[[[focus_tracking_presenter.py info here]]]
...(sometimes more output - seems to be typically LOCUS OF FOCUS info)...
[[[script adding more voluminous and identical info here]]]
...
^^^^^ PROCESS OBJECT EVENT %s ^^^^^

Since you are the main maintainer of the majority of the scripts in question, however, and you find the repetition of the info useful, it's fine to leave it in.  Can you please make the change to all the scripts listed in comment #4 to use debug.getAccessibleDetails(event.source)?
Comment 7 Rich Burridge 2007-11-09 16:43:06 UTC
Created attachment 98827 [details] [review]
Patch to fix the problem.

> Can you please make the change to all the scripts listed in comment #4 to
> use debug.getAccessibleDetails(event.source)?

You read my mind.
Comment 8 Willie Walker 2007-11-09 16:52:03 UTC
Thanks!  Please commit and feel free to close as FIXED.