Re: [g-a-devel] Not so easy: About pyatspi2 deprecationg and the merge of ATK and AT-SPI

[Piñeiro <apinheiro igalia com>]

On 10/31/2013 10:11 PM, Mike Gorse wrote:
> >     + 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. 

Something similar is done at Gecko and WebkitGTK (in fact, WebKitGTK
used as inspiration Gecko). On WebkitGTK ATK objects are wrapping
WekitCore accessibility objects. When a new ATK object is created, it
dynamically ask for a new gtype, based on the interfaces that should
implement based on that WebCore accessibility object. So we could do
something similar here. If you are interested, you can see the code here:
http://trac.webkit.org/browser/trunk/Source/WebCore/accessibility/atk/WebKitAccessibleWrapperAtk.cpp#L1076

> 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.

Well, probably there is a performance penalty check. But good to know
that it is possible.

> > 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.

Yep. In any case, in relation with "not all atk functions will be", we
could maintain some methods manually on atk. But at least the common
part would be shared.

> > 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.

I don't get it, could you elaborate this?

BR

-- 
----
Alejandro Piñeiro