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 _______________________________________________ gnome-accessibility-devel mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
