Re: Not so easy: About pyatspi2 deprecationg and the merge of ATK and AT-SPI

Hi all,

On Tue, 29 Oct 2013, Piñeiro wrote:

> Because although they are really similar, they are not equal. There are
> several differences between atk and libatspi API. On the case of the
> client/server different functionality, it is as easy as having different
> headers for each (and properly document the purpose of them). But there
> are cases not so easy to solve. For example, one tricky one is how
> polymorphims are implemented on both. atk uses inheritance. libatspi
> uses composition.
>
> What that means? Lets use as example the Text interface:
> * On atk there are some objects that are text objects. Those objects
> implement a specific interface, AtkText. And those objects know that
> implement that interface when they are created. In order to know if a
> object is a text object, you just need to use glib macros like this:
> ATK_IS_TEXT(object). And then in order to use it you just call atktext
> methods, because they are of the right type.
> * On libatspi there are some objects that are text objects. But to know
> if it is a text object, you don't use glib macros. You use a libatspi
> method. And in order to use it, you ask for an atspi-text object. So the
> API exposes the text interface as a separate component. In the practice,
> it is returning the same object, and atspi-accessible objects just
> implement all the interfaces, but the API exposes the functionality as
> composition, so it is not really "pure composition", but is a
> composition API after all. That is slightly less type safe, because you
> can call libatspi-text methods on a object that doesn't implement that
> interface.
>
> libatspi approach has an obvious advantage. When you create the object,
> you don't need to worry about which speficic interfaces it implements,
> it is an almost empty object. And which interfaces implement are
> requested only if needed, with a new DBUS call (GetInterfaces).
>
> And as we want to merge both, the question is, which approach do we want?
> * atk approach:
>     + more type safe
>     + after creation doesn't need a new DBUS call to know which
> interfaces implement.
>      - bigger creation overhead: it would be needed to know which
> interfaces the object implements when it is created. That means sending
> more info for each object created
> * libatspi approach:
>      - less type safe.
>      - after creation needs a new DBUS call to know which interfaces
> implement
>     + smaller overhead on object creation, as it only request which
> interfaces needs if needed. One could argue that most of the objects
> will need this call. But this doesn't need to be true. Applications
> creates tons of accessible objects, and just some of them are
> interesting to the AT.

The reason that AtspiAccessible implements all interfaces is that AT-SPI 
cannot know at compile time which interfaces that particular accessibles 
will implement. I'm not sure how difficult/possible it would be to 
dynamically create gtypes implementing particular interfaces, or if glib 
has a mechanism to allow an object to indicate which interfaces it 
supports at runtime. That being said, I don't see a good reason not to 
send the list of interfaces that an object supports when the object is 
created.

> 5. Why not autogenerate the headers for this just one library using the
> xml spec?
>
> I think that this was suggested by Benjamin some time ago. The
> explanation: at-spi2 provides all their funcitonality as a DBUS service.
> As with most of dbus programs all the functionality are defined on some
> xml files. This is really similar to what happened in the past with the
> idl files (CORBA/orbit related) at at-spi1. So one idea would be a step
> forward, and create most of the headers of this new library from those
> xml files. That would mean that most of the functionality would be added
> to those xml files, and then the headers (and probably more stuff),
> would be generated from them. I say "most functionality" because likely
> we would still need to maintain some of it. In any case, I have the
> feeling that current libatspi has as starting point those xml files.
> Mike, could you confirm that?.

That might be worth looking into, for the functions that are exposed over 
D-Bus (probably not all atk functions will be). The xml files are used for 
D-Bus introspection; they currently need to be maintained in parallel with 
the headers when libatspi API is changed in a way that affects the IPC.

> Reducing the amount of places to update each time the GNOME
> accessibility spec changes makes sense, would be a good idea, and it is
> worth investigate it. But taking into account all the still not answered
> questions, the amount of work that would need, and all the priorities we
> have right now (like Wayland), probably this is not the best moment to
> focus on this.

I think that this makes sense, at least in terms of what I should be 
spending time working on for the time being.

Thanks,
-Mike

_______________________________________________
gnome-accessibility-devel mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel