The UNO equivalent of object:text-attributes-changed is currently tagged as
"reserved for future use" and thus would have to be specified first ..

mt->obr: Please put some meaningful text into IDL and provide mapping in UAA/ATK
bridge.

After that send issue to Writer/EditEngine maintainer.

OOo 3.x now.

Is the object:text-attributes-changed expected to have any details parameter ? 

If not, we just need to fix the IDL (UNO <-> ATK bridging code is already present).

http://library.gnome.org/devel/atk/stable/AtkText.html#AtkText-text-attributes-changed
makes me think there are no details expected, i.e. OldValue and NewValue of the
UNO AccessibilityEvent can stay empty.

As the UNO <-> ATK bridge already implements that mapping, the IDL can as well
be changed when moving from VISIBLE_DATA_CHANGED to TEXT_ATTRIBUTE_CHANGED in
writer.

I think we should fix this in the next feature release -> adjusting target to
OOo 3.1

fixed in cws sw31a11y01 - changed files:
/sw/inc/viewsh.hxx
/sw/source/core/view/viewsh.cxx
/sw/source/core/inc/viewimp.hxx
/sw/source/core/view/viewimp.cxx
/sw/source/core/text/txtfrm.cxx
/sw/inc/accmap.hxx
/sw/source/core/access/accmap.cxx
/sw/source/core/access/acccontext.hxx
/sw/source/core/access/acccontext.cxx
revision 265955

Testing with ES reveals the following:
- Event object:visible-data-changed is no longer emitted at the described actions.
- Event object:text-attributes-changed is still not emitted at the described
actions.
--> My assumption is that the mapping of the UNO-A11y event
TEXT_ATTRIBUTE_CHANGED to ATK event object:text-attributes-changed is not function.

It also reveals that the UNO-IDL for UNO-A11y event needs also be adjusted.

OD->AB:
Please take over as discussed.
When you have your environment ready, let us together check, what is not function.

STARTED

Checked with AB that from OOo side everything wents well.
It seems that in one of the gtk libraries, namely libatk-bridge.so, a mapping
for event object:text-attributes-changed is missing.

Further investigation needed - send help request to williewalker.

ab->od: I don't think it makes sense to leave this one assigned to me

You are right.
This issue is also fixed from OOo's point of view.

Investigation reveals that the gtk library libatk-bridge.so is not mapping the
requested event.
Waiting for fixed gtk library and possible test environment.

Works with a fixed libatk-bridge.so provided by Li Yuan

verified with fixed libatk-bridge.so provided by Li Yuan

OD->ES: Please take over in order to verify again on master, when fixed
libatk-bridge.so is released - Thanks

Many thanks for working on this.

Just providing a trackback to the Orca bug:
http://bugzilla.gnome.org/show_bug.cgi?id=404046

I'd also love to test this if I can get my hands on a build that works with
OpenSolaris 2008.11 b109.

Will, I can run dev builds on OpenSolaris build 109. I forgot what I had to do,
but I just googled and found this thread on desktop-discuss. It sounds familiar. 

http://mail.opensolaris.org/pipermail/desktop-discuss/2009-March/011451.html

I tested with StarOffice 9.1.0 DEV300m41 (Build:9398) [CWS:swa11y32] on my
OpenSolaris b109 machine with Orca from trunk and did not get any
object:text-attributes-changed events.  Do you recall which version of
libatk-bridge.so Li gave you?  It might not be in b109.

OD->williewalker: Li send the library via private email at 2009-01-16 - you were
also on copy. I will send you the library from Li again via private email.

@od - thank you.  I'm less interested in the actual binary and more interested
in which version of libatk-bridge the changes were made in.  This is useful to
me so I know where we'll stand in terms of integration.  I was wondering if you
knew before I went digging.

From your response, I'm guessing you don't know.  :-)  So, I went digging
because this kind of cross reference and dependency is useful to have written
down.  The GNOME bug that was used to track this is as follows:

http://bugzilla.gnome.org/show_bug.cgi?id=567706

The relevant GNOME svn revisions are as follows, which seem to indicate it went
into GNOME 2.25.5 (and hence GNOME 2.26.0):

http://svn.gnome.org/viewvc/at-spi?view=revision&revision=1149
http://svn.gnome.org/viewvc/at-spi?view=revision&revision=1150

I don't see any commits for the gnome-2-24 branch.  I also checked the JDS
svn.opensolaris.org/svn/jds/spec-files/branches/gnome-2-24 patches to see if
there were any downstream fixes for OpenSolaris.  None have been done.

So, it looks as though one will need GNOME 2.26.0 or better along with some
version of OOo (3.1?) in order to get this functionality.

Thanks!

Hi all!

what do we do with that?
I had seen that fixed in 3.1 but apparently Willie found a fixed but a failed
which he discussed with OD.

Untill OD comes back from vacation nexr week, I set to 3.2 (doesn't seem to be a
showstopper anyway).

Then you can decide if we have to fix something more or if I can close.

This issue is solved in OOo, but a new version of library libatk-bridge is
needed in GNONE to get this issue solved in the complete environment.

OD->williewalker: Or did I miss anything?

@williewalker -> od: sounds fair enough.  I haven't had a chance to test with
GNOME 2.26.0, but if you have done so and have verified this is fixed, then I'm
fine with closing this as fixed.  We can always re-open it if necessary.

We have not tested the fix in GNONE 2.26.0 - we only tested it in an
environment, in which we have replaced the gtk library libatk-bridge.so by the
one which Li Yuan had provided.

Thus, I propose that Eric (ES) should perform a test in an environment with
GNONE 2.26.0 and OOo 3.1

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

Sorry this issue was wrongly closed. This issue will be reopened automatically.
And will be set after that back to fixed/verified.

Set to state 'fixed'.

Set back to state 'verified/fixed'.

Again. Sorry for the mass of mails.

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!

OD->joaniediggs:
Unfortunately, I can not check this issue, because I have no environment which
contains the adjustment from Li Yuan for libatk-bridge.so. This adjustment is
needed. Otherwise this library does not contain the needed event mappings - see
issue comments from January 2009.
But, I have checked OOo's Writer implementation in the debugger. The Writer code
triggers event object:text-attributes-changed. Thus, this part of the fix works.
I will check OOo's ATK bridge implementation, if it handles the corresponding
event correct. Please stay tuned.

joaniediggs: Can you please assure that the libatk-bridge.so handles the
corresponding event correct?

OD->joaniediggs:
I have checked OOo's ATK bridge implementation. It works fine.
I have copied the adjusted libatk-bridge provided by Li Yuan via eMail into my
environment and checked the fix of this issue.
I performed the steps given above. Accerciser reported
object:text-attributes-changed events when performing these steps.

The fix assures that OOo Writer emits this accessibility event for the change of
attributes at the paragraph as I have extracted it from the defect description.
This event is not emitted for changing attributes at certain characters or at a
word.
If the paragraph is empty and nothing is selected, the formatting "actions"
Control + B, Control + I and Control + U change the attributes for the
paragraph. Thus, this event is emitted.

joaniediggs->od:

w.r.t. "The fix assures that OOo Writer emits this accessibility event for the
change of attributes at the paragraph as I have extracted it from the defect
description. This event is not emitted for changing attributes at certain
characters or at a word." I suppose that's my fault for not explicitly including
that text actually be typed and, at least on occasion, selected prior to step 4
in which the formatting of text is changed. My apologies.

Regardless, as far as I am concerned, this bug is not fixed because
object:text-attributes-changed events are not always emitted when text
attributes change. In fact, for the two most common user behaviors in this area,
namely:

1. pressing Ctrl+{B,I,U} before and after typing some text
2. selecting only a portion of the paragraph and then pressing Ctrl+{B,I,U}

we get no object:text-attributes-changed events. :-( We need to get
object:text-attributes-changed events.

Would you prefer that I reopen this bug or create a new bug?

od->joaniediggs:
Ok, this issue has solved the defect that no object:text-attributes-changed
events are emitted for changing text attributes at the paragraph.

I would prefer a new issue for solving the defect that no
object:text-attributes-changed are emitted for changing text attributes at a
certain text portion. Please submit a corresponding issue.
For this issue we have to decide which accessible object should emit this event
and what data (<OldValue> and <NewValue>) this event should contain - let us
discuss this in the new issue.

This issue can then be closed as FIXED in my opinion.

joaniediggs->od Issue 104008 has been opened. Thanks!

Fixed and integrated => closing now..