Created attachment 177759 [details] [review]
provide toolkit name as an AtkAttribute

gail now provides toolkit = gail as an AtkAttribute of all gtk objects.

https://bugzilla.gnome.org/show_bug.cgi?id=598952

It really shouldn't make any difference to ATs what the toolkit is. 
What's the use case here ?

Widgets in any given toolkit cannot be counted on to share the same Atk implementation. With different accessible hierarchies and/or different events being emitted, knowing the toolkit helps ATs make the appropriate decisions.

(Yes, the 'please do it like Gtk+' requests have been made. And largely ignored.)

(In reply to comment #2)
> It really shouldn't make any difference to ATs what the toolkit is. 
> What's the use case here ?

Two specific examples:

* When there are a selection change default orca script only announce that if it was caused for an "up", "down" key and it is a ROLE_TABLE_CELL. This is because the principal use-case of selection on gail is the tree view. In the case of clutter/st we don't have that, but some kind of custom lists on gnome-shell are being implemented in that way, and we are going to provide the a11y support using selection changes [1]. I have a custom script that just speak up the selection change always (bug pending). Although probably this will go for a specific custom gnome-shell script, it is clear that the default behaviour couldn't be used for cally for a long time

 * AtkKeyEventStruct includes a string field, that is some cases is a symbolic name of the keypress. In the case of orca, can be used to speech out the key pressed (ie : "space"). In the case of gtk it uses gdk_keyval_name. Clutter doesn't have it and probably it will not have never. With the toolkit information, orca can load a custom cally script redefining the proper methods.  This one knows that this field will be empty, so it would try to find it. One could argue if this is a bug on cally atk implementation (or on atk definition of this structure), but for the moment is the easiest way to do that.

BTW: the component is still gtk (it should be gail)


[1] https://bugzilla.gnome.org/show_bug.cgi?id=634016#c2
[2] http://library.gnome.org/devel/atk/stable/AtkUtil.html#AtkKeyEventStruct

Why bother with this huge atk abstraction in the first place then, if each toolkit does it differently ?

From my perspective, the goal behind the changes (and associated documentation writing) is twofold:

1. Enhance and augment Atk to make it provide more readily-usable information to ATs based on what we've learned having used the current implementation for the past however-many years.

2. Encourage more standardized implementations across toolkits.

However, I do not think that once those changes are done and documented, all toolkits everywhere will suddenly share a single, identical implementation.

Just because there are differences in implementations -- differences which may exist for very good, toolkit-specific reasons -- does not mean that Atk does not need to be improved or better documented.

Anyway, I have no substantial objections to this, so feel free to commit.

Review of attachment 177759 [details] [review]:

Committed.