Reassigned to ES.

ES->OBR: Please have a look.

@pl: do we already have a corresponding VCLEVENT_ for this ? If so, which one ?

VCLEVENT_WINDOW_KEYINPUT, VCLEVENT_WINDOW_KEYUP ? I must admit that I don't have
the slightest idea who handles these shortcuts.

Well, these are the obvious (but unusable) ones. I was more referring to some
"toggle button switched state" event, which probably needs to get mapped to some
accessibility event in the UNO toolkit a11y implementation.

@pb: it seetms that VCLEVENT_TOOLBOX_CLICK is not send in this case (and not the
appropriate name either ;-)).

ping. :-)

There have been a lot of awesome improvements in 2.2-dev in the area of exposing
text attributes (THANK YOU!!!).  Any chance of squeezing in a fix for this one
for 2.2 as well?

Thanks in advance!

@joaniediggs: no chance because 2.2 is almost finished and the target milestone
of this task is 3.0.

target 2.3

What about adding some VCLEVENT_TOOLBOX_BUTTONSTATECHANGED?

Regarding VCLEVENT_TOOLBOX_BUTTONSTATECHANGED:  I, of course, couldn't tell you.
 :-)

However, just looking at the event name, I figured I'd ask:  Will that also
cause us to get events for the paragraph style, font name, and font size combo
boxes?  For instance, when the user presses Control+{1, 2, 3} the selected item
in those controls change.  We're not getting events for those changes.

pb: too late for 2.3 -> 2.4.

added myself to cc

MD: Due to the severity of this issue I raise the priority to P2.

I think sending the events is doable.

@joaniediggs: if we do it correctly you should get these events for every change
in any toolbar item; we just would send them each time our toolbar control gets
a new status.

Are all people involved with getting these events each time when the status
changes, regardless what source changed the status? Each cursor movement could
trigger the same events.

> Each cursor movement could trigger the same 
> events.

I assume that a cursor movement would only trigger the event if the status has
changed.  For instance, given "This is bold text" where "bold" is formatted to
be bold and the rest of the text is not: If I started arrowing from "This"
towards "bold" I would expect the following:

1. An event to let me know that the bold toggle button was checked when I moved
from the space before "bold" to the "b" of "bold."

2. An event to let me know that the bold toggle button was unchecked when I
moved from the "d" of "bold" to the space that follows "bold".

I would NOT expect events for the bold toggle button as I arrowed from "b" to
"o" to "l" to "d".

If this is what you mean, then, I for one would be very grateful for these
events.  Personally, I think it is up to the application (OOo) to expose the
information everyone (else) has access to.  (When I arrow to the "b" of "bold" I
visually see that toggle button change appearance).  It is up to the assistive
technologies (Orca) to decide if/how to present that information to the end user.

BTW, thanks for the priority bump MD!!  Not having these events is a significant
problem for users who are blind. :-(

Fine, so it looks as we can do it by just forwarding all status updates a
toolbar controller receives. 

Carsten, please take over

cd: Started.

Ok, I have committed my part of the fix: the UNO <-> ATK bridge now creates the
wrapper objects on the newly introduced VCLEVENT_TOOLBOX_BUTTONSTATECHANGED, so
the state change events are now bridged properly.

During my tests I noticed that OOo frequently crashes when closed while having
accerciser event logging turned on, but as this doesn't seem to happen with orca
and is also reproducible on the master, I have submitted issue 85292 for this.

cd: Fixed.

cd->es: Please verify on CWS.

Verified in CWS fwk83

This is now working well for:

toggle bold - control-B
toggle underlining - control-U
toggle italics - control-I

But is not working for things like:

Alignment-related:  Control+{L, R, E, J}
Heading-related:  Control+{1, 2, 3}
Revert to default style: Control+0

See comments in Orca bug #404046
http://bugzilla.gnome.org/show_bug.cgi?id=404046

Reopening for further evaluation by the OOo team.

Testing with AT-POKE:

Controls (buttons) like reft, right, centered, justified do send state event
("checked" in at-poke) when pressing the corresponding shortcuts -> cannot
reproduce.

Controls (combo boxes) like style, Font, Font size don't send their content changes.

- Changing summary because it ist not related to the shortcuts, but to the controls
- Retargetting -> 3.0

The previously defined event gets only fired for real toolbar buttons, but not
for combo boxes in toolbars. So at the time the selected entry changes, no
wrapper object has been created and thus no XAccessibilityEventListener is
attached to that object yet.

changed component

I introduced a new event VCLEVENT_COMBOBOX_SETTEXT, which triggers the creation
of wrappers for the list and the edit child objects of the combo-box.

However, since the list items seem to get thrown away and recreated every time,
the only reliable seems to be the object:text-changed events emitted by the
combo box edit field.

Fixed in CWS aqua11y02.

Re-assigned to QA for verification.

Verified in CWS aqua11y02 using:
- accersizer - event monitor - source: selected application - Event:
object:text-changed
- Paragraph 1: Style: Default ; Font name: Times ; Font size: 12
- Paragraph 2: Style: Heading 1 ; Font name: Arial ; Font size: 24

All 3 combo boxes delever the correct text-change events.

This issue is closed automatically and wasn't rechecked in a current version of
OOo. The fixed issue should be integrated in OOo since more than half a year. If
you think this issue isn't fixed in a current version (OOo 3.1), please reopen
it and change the field 'Target Milestone' accordingly.

If you want to download a current version of OOo =>
http://download.openoffice.org/index.html
If you want to know more about the handling of fixed/verified issues =>
http://wiki.services.openoffice.org/wiki/Handle_fixed_verified_issues