Re: [g-a-devel] Some thoughts about deprecating pyatspi and moving to introspected libatspi

[Nagappan Alagappan <nagappan gmail com>]

Hi 
Piñeiro,

On Tue, May 29, 2012 at 9:13 AM, Piñeiro <apinheiro igalia com> 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
gnome-accessibility-devel gnome org
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