After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 638920 - gail should provide toolkit as an AtkAttribute
gail should provide toolkit as an AtkAttribute
Product: gtk+
Classification: Platform
Component: Accessibility
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
Depends on:
Reported: 2011-01-07 16:15 UTC by Trevor Saunders (IRC: tbsaunde)
Modified: 2011-01-19 07:38 UTC
See Also:
GNOME target: ---
GNOME version: ---

provide toolkit name as an AtkAttribute (1.89 KB, patch)
2011-01-07 16:15 UTC, Trevor Saunders (IRC: tbsaunde)
committed Details | Review

Description Trevor Saunders (IRC: tbsaunde) 2011-01-07 16:15:23 UTC
all AtkObjects created by gail should have an AtkAttribute of toolkit with value "gail"
Comment 1 Trevor Saunders (IRC: tbsaunde) 2011-01-07 16:15:25 UTC
Created attachment 177759 [details] [review]
provide toolkit name as an AtkAttribute

gail now provides toolkit = gail as an AtkAttribute of all gtk objects.
Comment 2 Matthias Clasen 2011-01-09 19:56:50 UTC
It really shouldn't make any difference to ATs what the toolkit is. 
What's the use case here ?
Comment 3 Joanmarie Diggs (IRC: joanie) 2011-01-09 20:31:16 UTC
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.)
Comment 4 Alejandro Piñeiro Iglesias (IRC: infapi00) 2011-01-09 23:55:28 UTC
(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)

Comment 5 Matthias Clasen 2011-01-10 16:59:57 UTC
Why bother with this huge atk abstraction in the first place then, if each toolkit does it differently ?
Comment 6 Joanmarie Diggs (IRC: joanie) 2011-01-10 17:38:15 UTC
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.
Comment 7 Matthias Clasen 2011-01-12 03:58:28 UTC
Anyway, I have no substantial objections to this, so feel free to commit.
Comment 8 Li Yuan 2011-01-19 07:38:10 UTC
Review of attachment 177759 [details] [review]: