Removing target milestone from [blocked] bugs.  We have little control over them, so we're better off letting priority and severity be our guide for poking the related components.

The blocking bug has been marked as fixed.  Therefore, removing the blocked status.  I won't know if anything else needs doing to identify and/or process these events until I try it.  But that's now "on my list."  It'll be awfully nice to have this information exposed to us....

This is the second half of the Rich-JD bug exchange (one bug per head). ;-)

Rich, executive summary is that nothing's been done on this one due to the blockage. :-( What I have in mind is this:

Currently (as best we can), we announce when bold, underline, italics, and the various alignments have been toggled.  But there are quite a few controls on the formatting toolbar for which we've not gotten any events whatsoever, even after "tickling."  For instance, if the user presses Control+1 for a Heading 1. Strikethrough is another that comes to mind, although you may have to assign it a keystroke first.  Anyhoo.... Theoretically, if the blocking bug is truly fixed, we should be getting events when the user toggles these things via keyboard shortcut or mouse click.  If so, what needs doing w.r.t. this bug is to cause Orca to announce confirmation that the paragraph style or whathaveyou has changed.  (Changes to toggle buttons may JustWork(tm) as a result of the work we've already done around bold, etc.)

Hope this makes some sense.  If not, you know where to find me. :-)  Thanks!

(In reply to comment #3)
> If so, what needs doing w.r.t. this bug is
> to cause Orca to announce confirmation that the paragraph style or whathaveyou
> has changed.

Agreed.  Hopefully we will get reasonable events from OOo that give us at least the notification that the text attributes have changed.

> Agreed.  Hopefully we will get reasonable events from OOo that give us at least
> the notification that the text attributes have changed.

Just to be sure we're on the same page:  The bug fixed in OOo is (presumably) not going to cause us to be notified that the text attributes have changed (i.e. object:text-attributes-changed); it's going to cause us to be notified that the state (and/or value) of the widgets on the formatting toolbar has changed.

**Rich: Around line 2256 of StarOffice.py I've got a list of navKeys.  Left and Right should be added.  Thanks!**

Created attachment 104581 [details]
Orca debug output whilst testing whether the OOo bug was fixed.

It doesn't look to be like this bug is fixed, or else Control-1 doesn't
didn't do what I was expecting.

I applied the latest patch from bug #363830:
http://bugzilla.gnome.org/attachment.cgi?id=104578

and started up swriter from the OOo 2.4-dev m6 build.

I then added a single line plus Return. Then I pressed Control-1
(see KEYEVENT's starting at line 692). Visually the OOO bold "B"
image in the toolbar was selected.

This generated an "object:state-changed:checked" event (line 734):

OBJECT EVENT: object:state-changed:checked             detail=(1,0)
    app.name='soffice' name='Bold' role='toggle button' state='checked enabled focusable sensitive showing visible' relations=''

and Orca spoke:

SPEECH OUTPUT: 'Bold on'

So Joanie, what are the other magic keystrokes I really should be testing 
for, to see if this bug is fixed?

Thanks.

We do not seem to be getting events to let us know that the values of the combo boxes on the formatting toolbar have changed.  I thought we would have as part of the OOo fix. :-(  So I guess that bug ain't fixed.

I noticed that changing format does cause us to get object:visual-data-changed events for the relevant paragraph.  Perhaps we could use those?  Then again, Eitan indicates those are high-traffic events that we might not want to be attending to.  See http://bugzilla.gnome.org/show_bug.cgi?id=512503

So.... Maybe what we really want to do is request a different event from the OOo guys?  I see there is an object:text-attributes-changed.  If we had such an event, I assume we could use it to make the announcements instead??

Thanks. For the record, what keystrokes should I have been testing this with?

Control 0 for default paragraph style
Control 1 through 3 for heading 1 through 3

Beyond that, you can assign keystrokes to increasing and reducing the font size (they don't seem to come with keystrokes assigned).

Thanks. 

Eric Savery (in http://www.openoffice.org/issues/show_bug.cgi?id=70872) says:

"Verified in CWS fwk83"

I'm still not totally clear how to convert that into an OOo 2.4-dev release
but as it was only on 25th January, it's possible that this hasn't turned up 
in a publically available build yet.

Created attachment 105772 [details]
Orca debug output whilst testing this problem.

Just testing with OOo-dev2.4 (release candidate 1).

This is either still not implemented, or still broken in OOo. 
I'm not sure which.

At line 1847, I typed Control-1. This caused the single following 
event (at line 1889):

OBJECT EVENT: object:state-changed:checked             detail=(1,0)
    app.name='soffice' name='Bold' role='toggle button' state='checked enabled focusable sensitive showing visible' relations=''

You'll notice that the name is "Bold'.

This caused Orca to speak:

SPEECH OUTPUT: 'Bold on'

at line 1891. There were no other events.

Now if I type a Control-1 in oowriter (without Orca running), I
notice the the "Bold" toggle button on one of the icon-based
toolbars gets "highlighted".

So if Control-1 is for a type-1 header, this event is correct.

I also noticed that a combo box in the toolbar went from a selection
of "default" to "heading 1". We did not receive any accessibility events
for this change.

That's the bit that seems to be still not implemented or broken.

I'll now wait until the final OOo-2.4 release is available and test again.
If this is still the case, then I'll reopen the OOo bug.

Adjusting the target to 2.22.0. I'm fairly convinced that the
underlying OOo bug hasn't been fixed/integrated into OOo2.4-dev,
so I'm expecting to have to further adjust the target to FUTURE 
and reopen the OOo bug soon.

I recently reopened OOo issue #70872 so this one is blocked again.

This might need to be a new bug, but I'll start here.

Even if they fix the blocking bug, we're relying upon changes to the toolbar.  Turns out that if the user hides the toolbar (like Mike did at CSUN), we don't get the events and Orca doesn't announce things like bold being toggled (as we saw when Mike was formatting a document at CSUN). <grin>

We really need a better way to get this information.

As I stated in comment #7:

> I noticed that changing format does cause us to get object:visual-data-changed
> events for the relevant paragraph.  Perhaps we could use those?  Then again,
> Eitan indicates those are high-traffic events that we might not want to be
> attending to.  See http://bugzilla.gnome.org/show_bug.cgi?id=512503

(I've since discussed this with Will and the conclusion is that we indeed do not want to use those events because of the impact on performance.)

Continuing from comment #7:

> So.... Maybe what we really want to do is request a different event from the
> OOo guys?  I see there is an object:text-attributes-changed.  If we had such an
> event, I assume we could use it to make the announcements instead??

I tossed this out during our meeting with Malte, but I couldn't recall if the that was the correct event name, Will seemed to have questions about what event we wanted, etc., etc., so we kinda did get much further. :-(

Now that we're all back... I think that we do indeed want to ask for the implementation/exposure of an event from OOo that we can count on independent of the toolbar being visible and without hurting performance -- be that object:text-attributes-changed or something else.  My proposal is that we figure out what event we want and then open an RFE in OOo's issue tracker so that hopefully we can have it by OOo 3.0.

Thoughts?

(In reply to comment #14)
> This might need to be a new bug, but I'll start here.

I think this is probably the the right bug for now.

> > So.... Maybe what we really want to do is request a different event from the
> > OOo guys?  I see there is an object:text-attributes-changed.

object:text-attributes-changed seems like a reasonable thing to do - if we received one of those, however, we'd also need a way to determine what changed.  :-)  Would this be in the event any_data?  Or, would it be something that where we would need to save away the current attribute for future reference?

I opened a new issue for the object:text-attributes-changed event.  
http://www.openoffice.org/issues/show_bug.cgi?id=88069

I didn't know the answer to Will's question:

(In reply to comment #15)
> however, we'd also need a way to determine what changed.
>  :-)  Would this be in the event any_data?  Or, would it be something that
> where we would need to save away the current attribute for future reference?

I did a bit of searching and didn't find anything that clearly spelled out what we can/should expect from this event.  (Seems to me that this is largely up to the whims of app developers).  Therefore, I just didn't make any suggestions on this front; merely asked for the event and said thanks. :-)

Anyone with knowledge of, and/or strong opinions regarding, the anatomy of this event, do feel free to share that on the OOo issue. :-) :-) :-)

> (In reply to comment #15)
> > however, we'd also need a way to determine what changed.
> >  :-)  Would this be in the event any_data?  Or, would it be something that
> > where we would need to save away the current attribute for future reference?

From http://library.gnome.org/devel/atk/stable/AtkText.html#AtkText-text-attributes-changed, it looks like the AT is expected to do the work to determine what changed. :-(

Just a data point - on OpenSolaris 2009.06, I ran OpenOffice.org 3.1.0 OOO310m11 (Build:9399) [CWS:ooo31osol] along with accerciser.  I had accerciser track object:text-attributes-changed events.

When I selected some text and pressed Ctrl+b or Ctrl+i to change attributes, I didn't get any events.  So, it looks like the OOo fix hasn't landed in a convenient release for us yet.

The blocking bug is marked as fixed. Changing the status of this one to "to verify" and assigning to myself.  If this is fixed in OOo 3.2, we can start looking at how to implement this feature in Orca. 

Tested with OOo-dev 3.1.1 (OOO310m17 Build:9415) in OpenSolaris build 118 (GNOME 2.26.2) which is the latest dev build available to the outside world as far as I am aware.

No object:text-attributes-changed events seen here.

Looking at the blocking bug, I'm a bit confused about what bits I should have and whether or not I have them. Perhaps the fix is in an "internal" build? Anyhoo, resetting the summary to [blocked].

Sorry for the spam. I just found out that the latest dev build of 3.0.0 is actually the latest dev build of 3.2. I'm not sure how I was supposed to know that, but now that I do....

I can confirm that we're getting object:text-attributes-changed events in OOo-dev 3.2.0/DEV300m53(Build:9412)

Unblocking.

<sigh>

This just in from the spoke-too-soon department (My comment on the blocking bug):

~~~~
Hi all. I just tested this in OOo-dev 3.2.0 DEV300m53 (Build:9412). The
following seems to be the case:

1. If you select an entire paragraph first, the events are emitted as expected.

2. If you select a character or word instead, or don't select anything (i.e. if
you perform the steps in the opening report), the events are not emitted.

Assuming I'm using a build that includes the intended fix, we really could use
having these events even when a full paragraph is not selected. Shall I re-open
this bug or open a new one?

Sorry and thanks!
~~~~

Just a quick note that Joanie has also verified http://qa.openoffice.org/issues/show_bug.cgi?id=88069 has been fixed in the swa11y32_2nd_en-US_SolarisIntel.tar file Thomas Lange made for me (300m51(Build:9408)[CWS:swa11y32_2nd]).

Changing the status from 'blocked' to 'to verify' because the blocking bugs are marked as fixed.

Note: Verification doesn't necessarily mean that Orca is doing the right thing yet; merely that in theory we should be able to implement what we need to do because we're getting the expected events from OOo.

I've verified it in an accessibility build that the OOo guys provided to me. It is not yet integrated into the releases of OOo yet.

In order to make use of their fix, we are going to have to do some work on our end. Unfortunately, the at-spi even for object:text-attributes-changed is merely and indication that *something* has changed; not *what* has been changed. So we're probably going to have to maintain some attribute state, wait for the event, and then make a comparison. Shouldn't be too difficult.

Planning spam. Sorry!