Can you tell me a test case for this bug?

Sorry for the incomplete report.

I mean when the accessible-name changed (e.g. by atk_object_set_name),
"property-change:accessible-name" signal will be sent out. Gnoperniucs
should listen on that and report the new name of the widget.

This is not something we should do in all cases (think of a clock 
whose text & name are both changing every second). 

Bolin: what is the specific case in Mozilla/Evolution (or whatever) 
that you are trying to address with this?  In discussions, we are 
thinking that name changes to a window title, a status bar item, or 
the focused item should be spoken, and all other changes ignored.  
Would this meet your needs?

Right. Report for focused widget is sensible.

My current situation is: in evolution calendar day view model, when
you click another day from the calendar on the right, the day view was
changed to reflect that change. That means, the title and content of
the  day view widget is changed, and day view object is the same. I
use the title as the accessible name of the day view widget, and
re-set the name to reflect the change of date, expecting gnopernicus
to read the new  name. (All the time, the day view widget has the focus).

I saw that in this case the calendar is a collection of objects, one
for every day of the month. Every of those objects is a focusable one.
In my opinion, the situation described above is not the real case. In
case of clicking a day, the selected day should be the focused object,
not other object.

Important: All my observations are on the evolution from Red Hat 8.1
distribution because I didn't succed to compile the evolution from CVS.

Bolian,

I made some changes(in CVS) in gnopernicus to reacts when the name of
current focused object changed. Can you check if this works for
evolution in case described by you?

I checked and gnopernicus works fine if the name of clock applet from
Top Panel change.

adding accessibility keyword

remus,

I tried the new version with my case, it works.  Thank you.