Hi Piñeiro,
On Tue, May 29, 2012 at 9:13 AM, Piñeiro <[email protected]> wrote: > On 05/29/2012 04:52 PM, Brian Nitz wrote: > > On 05/29/12 02:11 PM, Piñeiro wrote: > >> Hi, > >> > >> last week we talked about that during IRC and it was also an item on the > >> weekly meeting. Mike Gorse has an action item to make some > >> investigation, but meanwhile I would like to start a little debate as > >> part of that investigation. > >> > >> One of my concerns is related with the plan of stopping to have two > >> different accessibility API. This is explained in this bug [1], but in > >> summary, using Benjamin diagram, what we have right now is this: > >> > >> AT<= libatspi => AT daemon<=DBUS=> bridge<=ATK=> application > > Do you suggest moving to something like this? > > > > AT<=ATK=>{some IPC for replicating application object in AT and vice > > versa?}<=>ATK<=>Application > > Well, your diagram seems to suggest more changes that I proposed. I'm > talking about something like this: > > AT<= ATK => AT daemon<=DBUS=> bridge<=ATK=> application > > So ATs (like Orca) will use ATK and toolkits implementor will implement > ATK methods. All people using ATK. > > If you want more details, take a look to the comments of the bug I was > talking about [1] > > > >> > >> So in the server side (application) we have an ATK object, and in the > >> client side (AT) we have a libatspi object, with the same purpose and > >> just slightly different. The reasons of having two different APIs for > >> the same are AFAIK, historical, due the way idls was used on the Corba > >> based AT-SPI. So we concluded that it would be good to check if it would > >> be possible to get rid of one of those APIs. So maintaining ATK, we > >> would have an ATK object at the application side, and a equivalent ATK > >> object at the AT side. One less API to maintain etc. But we are still > >> working on the details. > >> > >> Well, my concern is the following one. If we deprecate pyatspi2 and more > >> to a gobject-introspected libatspi, ATs like Orca and Accerciser would > >> require to make an effort to change to that new library. > > > > LDTP and Dogtail as well. > > True. > > > > >> If we > >> eventually get rid of atspi in favor of a client-side implementation of > >> ATK, ATs would require to make a new port. This seems like doing twice > >> the same work, and we already know that our resources are scarce. > >> > >> So as far as I see, we have two options: > >> > >> a) Conclude that ATK move to the client-side will take too much and go > >> on with the current plan to deprecate pyatspi2 and use > >> gobject-introspection bindings for at-spi. Port ATs. If in the end ATK > >> is used at the client side make a new port. > >> b) Conclude that doing two ports doesn't worth. Focus first on moving > >> ATK to the client side. Deprecate both pyatspi2 and libatspi. Port ATs > >> to gobject-introspection based bindings for ATK. > >> > >> Thoughts? > > > > It looks like both options deprecate pyatspi2 so wouldn't both require > > considerable work for ATs such as Orca, Accerciser as well as LDTP and > > other test automation built on pyatspi? > > Well, my email started with the assumption that deprecate pyatspi2 was > "ok", as that was the conclusion of last weekly meeting. Anyway, as I > said on my previous mail, was a tentative ok while we are checking the > impact. So yes, that would require considerable work, but both Joanmarie > and Javier Hernandez were positive about that. As part of the further > investigation, ldtp people are required to be contacted. > I'm fine changing LDTP, if Orca / Accerciser are getting updated. Thanks Nagappan > > As I explained on my mail, my main concern is adding too much work if in > the end we also move from atspi to a client-side ATK. > > > > >> > >> Finally I would also want to mention something about those details we > >> are working on. On that bug [1], Mike mentions that one solution could > >> be move all the IPC related code to ATK. And as I mention to the bug, > >> that would mean add a new IPC dependency on ATK. IMHO, we don't need to > >> move all the IPC code to ATK to get rid of atspi API. One option could > >> be just have a client-side ATK implementation. So: > >> * ATK keeps being the abstract accessibility API. Represents > >> accessibility objects. > >> * On the server side, different toolkit implements ATK. > >> * On the client side, atspi also implements ATK, taking care of > >> the IPC. > >> > >> Thoughts? > > > > I'm wondering which (if either) of these options would work better for > > the use-case where the AT is on a different platform from the > > application. (e.g. someone runs a Linux app inside a VirtualBox via > > JAWS on Windows or someone accesses a Windows app over VNC via Orca. > > Shouldn't this be possible to have a bridge from ATSPI to and from > > IAccessible2 so that there would be more seamless accessibility into a > > VNC window or inside a VirtualBox machine? If so, would it be easier > > to implement with a client-side or a server-side ATK? > > I don't see any difference. > > > > >> > >> > >> [1] https://bugzilla.gnome.org/show_bug.cgi?id=652777 > >> > > > > > > BR > > -- > Alejandro Piñeiro Iglesias > > _______________________________________________ > gnome-accessibility-devel mailing list > [email protected] > https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel > -- Linux Desktop (GUI Application) Testing Project - http://ldtp.freedesktop.org Cobra - Windows GUI Automation tool - https://github.com/ldtp/cobra http://nagappanal.blogspot.com
_______________________________________________ gnome-accessibility-devel mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
