[webkit-efl] Support for WAI-ARIA standard.

[Piñeiro]

On 10/31/2012 04:33 PM, Raphael Kubo da Costa wrote:
> Thanks a lot for the detailed explanation :-) A few comments and
> questions below.
>
> Piñeiro <apinheiro at igalia.com> writes:
>> at-spi2 is a library that includes the client-side library (libatspi)
>> and the DBUS daemon.
>>
>> ATK is one of the possibles server-side library (at this moment there
>> are only two, ATK and QtAccessible).
>>
>> [...]
>>
>> In order to expose the information from the server to the client, DBUS
>> is used. So it is required a library doing those DBUS calls between the
>> server and the client. A bridge. For the case of GNOME, in order to
>> avoid to have a bridge for each toolkit, each toolkit implements the ATK
>> headers and a ATK-bridge (or adaptor) was created. This bridge uses ATK
>> API in order to know how to expose the information.
> What do you mean by "implementing the ATK headers"? I've always heard of
> ATK as something from GNOME, and the ATK headers as just containing a
> set of C functions which depend on glib, not something more high-level
> like a set of IDL definitions.

Sorry, "implementing the ATK headers" is not a good sentence. I should
have used "implementing the ATK interfaces". glib allow to define
classes and interfaces. Most of the ATK API are glib-interfaces. You can
take a look of that API here:

http://developer.gnome.org/atk/stable/

And yes, as you said, right now ATK doesn't have a set of IDL
definitions. On the past, with the CORBA based at-spi, it has a set of
IDL definitions. ATK was based mostly on those at-spi IDLs. With the
current DBUS based at-spi2, those IDLs are not used anymore, but they
can be used as a high-level documentation.

>
> Additionally, are ATK and ATK-bridge different things?

Yes. As I said ATK is a set of abstract interfaces. Their purpose is
abstract any toolkit, guided by the accessibility needs. ATK-bridge is a
module that expose the application information to the accessibility
tools. It uses ATK API in order to get and react to that information. So
instead of having a gtk-bridge, a clutter-bridge and a webkitgtk-bridge,
gtk, clutter and webkitgtk implements ATK, and the atk-bridge expose the
information using ATK API.

>
>> ATK is already toolkit independent. In fact was created with that
>> purpose. Although the most common know implementation is GTK, is not
>> tied to it. Firefox ATK implementation have some nits of GTK, but this
>> is because Firefox is already using GTK on Linux. I implemented the ATK
>> support for Clutter, and it doesn't have any GTK reference at all.
>>
>> [...]
>>
>> But the case of webkit is different. Thanks to the work done on
>> webkit-gtk webkit already have a lot of ATK implementation done. And the
>> bridge works fine (both for webkit1 and webkit2). Implementing a new
>> bridge (something like webkit-bridge) seems like an overkill to me.
> I may have expressed myself wrongly -- ATK itself does not depend on
> GTK+, but it does depend on glib, right? I wasn't thinking of some
> webkit-bridge, but perhaps an EFL-bridge (I'm not even sure if this
> concept even make sense, mind you).

Ok, thanks for the explanation. Yes probably an EFL-bridge would make
more sense. Anyway:
 1.) Taking into account the comments from others, the dependency on
glib is not a problem anymore
 2.) That EFL-bridge doesn't exist at all. That bridge would need to do
a mapping/wrapping between EFL toolkit and the accessibility DBUS
services/calls that at-spi2 requires. But webkit already had a lot of
work done on the accessibility mappings/needs on the ATK code. Again,
IMHO, use the ATK code would allow to reuse a lot of code. WebkitGTK
port plans to keep improving the atk support. So EFL developers would
only need to take care of any toolkit difference. Creating a EFL-bridge
would mean creating a new non-trivial module from scratch.


BR

-- 
Alejandro Piñeiro Iglesias