Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | No a11y events when expanding/collapsing items in navigator | ||
---|---|---|---|
Product: | Writer | Reporter: | williewalker <walker.willie> |
Component: | ui | Assignee: | eric.savary |
Status: | CLOSED FIXED | QA Contact: | issues@sw <issues> |
Severity: | Trivial | ||
Priority: | P3 | CC: | eric.savary, issues, malte_timmermann |
Version: | OOo 1.0.3 | Keywords: | accessibility |
Target Milestone: | --- | ||
Hardware: | Sun | ||
OS: | All | ||
Issue Type: | DEFECT | Latest Confirmation in: | --- |
Developer Difficulty: | --- |
Description
williewalker
2008-07-24 18:13:11 UTC
OOo 3.2 Trackback to the Orca bug: http://bugzilla.gnome.org/show_bug.cgi?id=356060 OD: Please have a look Sorry, I forgot to set confirmed. Ok, confirming issue as ES already wanted to do OD->williewalker: I am working on with issue. But, I have got a problem. The accessible objects, which represent the items in the navigator's tree, are transient. Thus, it does not make sense to emit events for them - no one would listen to a newly created accessible object. The accessible object, which represents the navigator's tree, could emit an event stating that the expanded state of one of its children has changed including a newly created accessible object of this child in this event - something like "object:descendant-state-changed-expanded". Would this be acceptable for you? Do you have another suggestion? williewalker->OD: the AT-SPI event model is such that one registers for event types in general instead of registering for events on specific objects. So, it should be OK to emit object:state-changed:expanded events for these objects. A GTK+ example of where we see this can be found in the gtk-demo application (/usr/demo/jds/bin/gtk-demo on OpenSolaris). The "Icon View" item in the tree table is an accessible table cell object with the EXPANDABLE and TRANSIENT states and it emits the appropriate events. Here's some examples from accerciser when I expand/collapse the object: object:state-changed:expanded(1, 0, None) source: [table cell | Icon View] application: [application | gtk-demo] object:state-changed:expanded(0, 0, None) source: [table cell | Icon View] application: [application | gtk-demo] Ok. Thus, the proposed solution in OOo and OOo's ATK bridge will be: - emit events for expanding/collapsing of a certain tree item in OOo at the accessible object representing the navigator's tree - the event will contain a newly created OOo accessible object representing the tree item. - convert these events in the ATK bridge to events of newly created ATK objects representing the corresponding tree item. Just for clarification - how does the OOo implementation treat transient objects? My understanding of transient objects is that they should tend to persist as long as they are rendered on the screen. So, for example, if one arrows up and down the transient items of a tree, the accessible objects should remain the same as long as they are still painted on the display. Thus, changing the state of the object, such as expanding or collapsing it, should not cause the old accessible peer for that object to be destroyed and a new one created. Instead, the same accessible should be used. In this case the internal accessible object representing a navigator's tree item is not hold by OOo core code itself. Probably, a reference is hold by the bridge, which would keep the accessible object alive. But, I do not think that this is the case for transient marked accessible objects. Thus, the typical life time of an accessible object representing a navigator's tree item is very short, even if the list item is visible on the screen. E.g., Each call to <[accessible object of tree]::getAccessibleChild( i )> creates a new accessible object for the tree item. Emitting the object:state-changed:expanded is still the appropriate thing to do. Given that there are unknowns in the implementation, let's see what happens with the life cycle of the objects. We have code in Orca that attempts to deal with different accessibles being used for the same visual object on the screen. So, if we get different accessibles in this case, Orca's code might work and/or we might be able to make it work. Thanks! Yes, I am also be sure that it will work. adding new constants to com::sun::star::accessibility::AccessibleEventId indicating that a list box entry has been expanded respectively collapsed - change file: /offapi/com/sun/star/accessibility/AccessibleEventId.idl, rev. 271454 adding new vcl event ids VCLEVENT_LISTBOX_ENTRY_EXPANDED and VCLEVENT_LISTBOX_ENTRY_COLLAPSED - changed file: /vcl/inc/vcl/vclevent.hxx, rev. 271469 emit vcl events list box entry expanded resp. collapsed - changed file: /svtools/source/contnr/svtreebx.cxx, rev. 272330 process vcl events list box entry expanded resp. collapsed in order to emit corresponding accessibility events - changed file: /accessibility/source/extended/accessiblelistbox.cxx, rev. 272331 map accessible events list box entry expanded resp. collapsed to corresponding atk events - changed file: /vcl/unx/gtk/a11y/atklistener.cxx, rev. 272333 OD->ES: Checked in internal installation set of cws swa11y32_2nd - please verify This fix has been confirmed by the Orca team using the swa11y32_2nd_en-US_SolarisIntel.tar file Thomas Lange made for me (300m51(Build:9408)[CWS:swa11y32_2nd]). Many thanks! Thanx for verifying! Fixed and integrated => closing now.. |