Re: [g-a-devel] At-spi, and adding support for other display servers/desktop environments.

[Piñeiro <apinheiro igalia com>]

On 08/30/2013 02:40 PM, Luke Yelavich wrote:
> Hi folks,
> Another topic that I originally intended to raise at the last meeting is about at-spi, and refactoring it 
> to be more easily extendable for use with other display servers/desktop environments. As is likely known by 
> most people reading this list, the beginnings of this work have been started by Mike Gorse in at-spi2-core 
> 2.9.90.
>
> I have a couple of questions with regards to the roadmap for at-spi2-core going forward:
> 1. What is the roadmap for at-spi with regards to supporting Wayland?
The roadmap would be something like this:
1) Being able to compile at-spi2 without and X dependency
2) Test at-spi2 on wayland with 1), writing down what is working and
what is not (regressions).
3) Internal cleaning: the poster boy case here is removing the xevie code.
   From my own previous tests, I can conclude that current at-spi2
device event API is a mess. In fact, some stuff that initially was
thought to be obtained through device events (like key events) was moved
to object events, as workarounding that was easier. Documentation is
also poor.
4) Update of the X code
5) Implement the same functionality on some of the new window managers
(community upstream is right now focused on Wayland).

This seems a sensible list of items to work on. The only vague details
are related with dates. So some extra comments:
1) was already done by Mike, although as you know, it seems that there
are some regressions to deal with.
2) Right now we are just in the middle of the end of this cycle, trying
to tie all the loose knots, so this is not the best moment. Joanmarie
and me were talking about that, and probably it would be good to make a
kind of mini-hackfest at Boston Summit (this year again at Montreal),
using the most of having some wayland people around.
3) 4) During GUADEC Keith Packard, a developer with experience on X,
came to the a11y BOF. Some of the conclusions is that xevie needs to
go(we already concluded that), and a lot of the current X code needs to
be updated, in order to use newer stuff like XInput2.
5) Probably conditioned to 1)2)3)4). In any case, during GUADEC I also
made some questions on the Wayland track. They see all the needed
support from Wayland feasible, and they seem open to suggestions and
feedback.

Highlighting a specific item, I think that the conversation we had
during GUADEC with Keith Packard, and the Wayland maintainers, give us a
better global understanding of the whole situation.

> 2. Has any thought been given to detecting what backend to use at runtime?

This is a tricky question. In fact the same issue, bug talking about
gnome-shell, was discussed during GUADEC on the release-team meeting.
Right now gnome-shell has two binaries, but probably in the future they
will switch to just one binary. But they don't have a final answer yet
(and probably Unity people are discussing about the same). I guess that
at-spi2 could go for some of those situations. Anyway, in the worse
case, different binaries and packages (X, Wayland, Mir) could be created.

> Finally, given Ubuntu's divergence somewhat with the use of Mir and Unity, I am wondering whether upstream 
> would be willing to carry any code that concerns this desktop environment and display server. 
After a look to the code and features, the big chunk of at-spi2
functionality is X/Wayland/Mir independent. I'm specifically talking
about accessibility object related events vs devive related events. So
imho, the priority from upstream would be ensure that that is working
without X (like those properties-like on X used by at-spi2), and provide
a way to add backends in order to implement the functionality that
depends on the display server.

> An alternative is to refactor at-spi2-core such that the backend mechanism allows for pluggable modules to 
> be loadable, thus allowing the Unity and Mir interface to be maintained out of tree.
As I said, in the end it will be needed some way to allow the support to
different display servers. Although Wayland is here, on the present and
at the future, we need to support X as well. Support for X, and support
for Wayland is needed. So Mir is just another actor in the mixture.
Somehow we would need to support different backends on at-spi2. In any
case, I prefer a common backend mechanism, instead of pluggable modules
loaded on runtime.

> There is currently no API for at-spi2 to interface with Unity and Mir, but the hope is to get that 
> implemented within the next couple of months.
Well, all the APIs on X used by at-spi2 were not created due at-spi2.
For example, xevie, although announced as an accessibility related
extension, was in fact created as a debug tool. And it seems that
Wayland have the proper flexibility to support accessibility needs. What
I mean is that I don't foresee too many specific accessibility related
APIs here.

> I'd be interested in learning about at-spi2 plans as per my above queries, and will be implementing the 
> at-spi2 to unity interface, so I am happy to help with the refactor as well.
I hope that the previous comments would help you on this. The summary is
that we are working on that, we learned some stuff during the process
that will help us to move forward, and as usual the only bottle neck is
about having free resources to do the work.

BR

-- 
Alejandro Piñeiro Iglesias