headers
Mike Gorse | 9 Nov 2010 10:15
Favicon

ANNOUNCE: at-spi2 1.91.2 released

AT-SPI2 1.91.2 is now available for download at:

http://download.gnome.org/sources/pyatspi/1.91/
http://download.gnome.org/sources/at-spi2-core/1.91/
http://download.gnome.org/sources/at-spi2-atk/1.91/

Notes
=====

A list of work required before the full release can be found at:

http://www.a11y.org/atspi-todo

What's changed in AT-SPI2 1.91.2
===============================

core:
* The desktop object now returns ROLE_DESKTOP_FRAME rather than ROLE_UNKNOWN.

atk:
* FIxed BGO#563546: Removed the g_atexit hook.

What is AT-SPI2
===============

AT-SPI2 is a D-Bus based accessibility framework. It defines a D-Bus
protocol for providing and accessing application accessibility
information. The project includes a library for bridging the D-Bus
protocol to the ATK API, allowing Gtk based applications to be made
accessible. It also contains a client (AT) side library in Python.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mike Gorse | 16 Nov 2010 05:00
Favicon

ANNOUNCE: at-spi2 0.4.1 released

AT-SPI2 0.4.1 is now available for download at:

http://download.gnome.org/sources/pyatspi/0.4/
http://download.gnome.org/sources/at-spi2-core/0.4/
http://download.gnome.org/sources/at-spi2-atk/0.4/

Notes
=====

A list of work required before the full release can be found at:

http://www.a11y.org/atspi-todo

What's changed in AT-SPI2 0.4.1:
===============================

core:
* The desktop object now returns ROLE_DESKTOP_FRAME rather than ROLE_UNKNOWN.

atk:
* FIxed BGO#563546: Removed the g_atexit hook.

pyatspi:
* Check for python-xlib in configure.

What is AT-SPI2
===============

AT-SPI2 is a D-Bus based accessibility framework. It defines a D-Bus
protocol for providing and accessing application accessibility
(Continue reading)

Permalink | Reply | 0 comments |
headers
Luke Yelavich | 18 Nov 2010 06:50
Favicon

The atk bridge, and a location to place the atk-bridge shared object.

Hi all,
Since we now have more than one toolkit other than GTK making use of atk for accessibility, I think its time we
revisit the discussion about a location for the atk bridge shared object, i.e other than the GTK module
directory. From skimming through the mail from this list, this was previously discussed, without a
concensus reached. Perhaps if a proposal is offered, it could then be improved upon/discussed further,
to help reacha concensus much sooner, and thereby be implemented ASAP.

I am still learning about the finer details of atk, so please forgive me if my proposal is somewhat lacking in
its assessment and consideration of all the pieces in the puzzle. So far as I understand, this is not a
complicated issue, therefore it should be relatively simple to solve.

* We still use a shared object, in a similar form to what we have now, except the object doesn't bare any
resemblance to gtk in terms of method names.
* The shared object is placed in $libdir/atk, and called atk-bridge.$platform_shared_object_extension
* The libatk API is extended to provide methods for locating and managing the bridge.
* A new GTK module is created that wraps libatk to load the atk-bridge shared object for the currently
running app.

Suggestions, criticisms etc, most welcome. As stated, I may have missed something, so if I have, please
point it out.

Luke
Permalink | Reply | 5 comments |
headers
Luke Yelavich | 18 Nov 2010 06:36
Favicon

At-spi over dbus performance.

Hi all
I tested at-spi via dbus a couple of days ago, and can certainly notice the performance difference with some
things, and not so much with others. The one area I particularly notice a difference is when reading the
pidgin buddy list with orca. Reading down the buddy list takes a while to speak an individual item, say half
a second. This gets progressively longer as I get further down the list.

I am wondering whether there is any code being worked on outside the main at-spi2 git trees to address
performance. The Ubuntu desktop team would really like to switch to using at-spi over dbus for Natty, but
performance is one area where we feel needs improvement if we are to make that choice. The Ubuntu desktop
team may be able to provide extra help in solving performance issues in the future.

I notice on the at-spi dbus migration page that nothing specific is mentioned about performance. What has
been considered to improve things? Perhaps I can let the Ubuntu desktop team know what is being
considered, and better ideas could be put forth.

Thanks

Luke
Permalink | Reply | 4 comments |
headers
Sven Herzberg | 18 Nov 2010 13:24

Re: The atk bridge, and a location to place the atk-bridge shared object.

Hi,

Am Donnerstag, den 18.11.2010, 16:50 +1100 schrieb Luke Yelavich:
> Since we now have more than one toolkit other than GTK making use of
> atk for accessibility, I think its time we revisit the discussion
> about a location for the atk bridge shared object, i.e other than the
> GTK module directory. From skimming through the mail from this list,
> this was previously discussed, without a concensus reached. Perhaps if
> a proposal is offered, it could then be improved upon/discussed
> further, to help reacha concensus much sooner, and thereby be
> implemented ASAP.

I haven't followed this with much attention, but that other toolkit,
does it use GTK+'s module interface to load the so?

My recommendation would be to split up the so into a shared libraries
and one loadable module per toolkit (which would then, be placed into
the module folders of the corresponding toolkits).

As long as the at-spi so exports GTK+'s module interface it seems to
make sense to keep it in GTK+'s module folder, doesn't it?

Just think of all the side effects that you had by patching GTK+ to load
at-spi from a different folder.

Regards,
  Sven

PS: What is the second toolkit you're talking about? If that one uses
GTK+'s module API to load at-spi, maybe it makes sense to have that
(Continue reading)

Permalink | Reply | 1 comment |
headers
Piñeiro | 18 Nov 2010 14:06
Favicon

Re: The atk bridge, and a location to place the atk-bridge shared object.

From: Luke Yelavich <themuso <at> ubuntu.com>

> Hi all,
> Since we now have more than one toolkit other than GTK making use of atk for accessibility, I think its time
we revisit the discussion about a location for the atk bridge shared object, i.e other than the GTK module
directory. From skimming through the mail from this list, this was previously discussed, without a
concensus reached. Perhaps if a proposal is offered, it could then be improved upon/discussed further,
to help reacha concensus much sooner, and thereby be implemented ASAP.

Yes, this is a old discussion. I guess that you read my mail about
this [1], almost one year and a half ago.

> I am still learning about the finer details of atk, so please forgive me if my proposal is somewhat lacking
in its assessment and consideration of all the pieces in the puzzle. So far as I understand, this is not a
complicated issue, therefore it should be relatively simple to solve.

Well, IMHO it is somewhat complex ;) the main complexity is avoid to
interfere with the current working applications and how to get the
placement of the shared module.

> * We still use a shared object, in a similar form to what we have now, except the object doesn't bare any
resemblance to gtk in terms of method names.

Right now the only method names resembling gtk are the hooks
gtk_module_init and gtk_module_shutdown *

Anyway, althouh the current atk bridge provides this hooks, it also
provides gnome_accessibility_module_init. This is the one I use on my
patch to load the bridge on gnome-shell [2].
(Continue reading)

Permalink | Reply | 2 comments |
headers
Piñeiro | 18 Nov 2010 14:16
Favicon

Re: The atk bridge, and a location to place the atk-bridge shared object.

From: Sven Herzberg <herzberg.sven <at> googlemail.com>

> Hi,
> 
> Am Donnerstag, den 18.11.2010, 16:50 +1100 schrieb Luke Yelavich:
>> Since we now have more than one toolkit other than GTK making use of
>> atk for accessibility, I think its time we revisit the discussion
>> about a location for the atk bridge shared object, i.e other than the
>> GTK module directory. From skimming through the mail from this list,
>> this was previously discussed, without a concensus reached. Perhaps if
>> a proposal is offered, it could then be improved upon/discussed
>> further, to help reacha concensus much sooner, and thereby be
>> implemented ASAP.
> 
> I haven't followed this with much attention, but that other toolkit,
> does it use GTK+'s module interface to load the so?

Clutter based applications like GNOME Shell require to load by hand
atk-bridge. In this case is uses g module code. You can see a patch
here [1]

And not use gtk module interface is the reason is hard to get where
the atk-bridge is. In fact I proposed to export extra information from
the gtk modules [2], but I agree that this was not a long term
solution.

> My recommendation would be to split up the so into a shared libraries
> and one loadable module per toolkit (which would then, be placed into
> the module folders of the corresponding toolkits).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Piñeiro | 18 Nov 2010 15:54
Favicon

Re: At-spi over dbus performance.

From: Luke Yelavich <themuso <at> ubuntu.com>

> Hi all
> I tested at-spi via dbus a couple of days ago, and can certainly notice the performance difference with
some things, and not so much with others. The one area I particularly notice a difference is when reading
the pidgin buddy list with orca. Reading down the buddy list takes a while to speak an individual item, say
half a second. This gets progressively longer as I get further down the list.
> 
> I am wondering whether there is any code being worked on outside the main at-spi2 git trees to address
performance. The Ubuntu desktop team would really like to switch to using at-spi over dbus for Natty, but
performance is one area where we feel needs improvement if we are to make that choice. The Ubuntu desktop
team may be able to provide extra help in solving performance issues in the future.

Mike Gorse is working on at-spi2 performance, like caching on pyatspi,
and moving somethings from python to C. He have more details.

> I notice on the at-spi dbus migration page that nothing specific is mentioned about performance. What has
been considered to improve things? Perhaps I can let the Ubuntu desktop team know what is being
considered, and better ideas could be put forth.

Well, I guess that if it is not mentioned because is because this page
is just about the migration and how you can install both at the same
time, but it is strange that this is not mentioned, do you have the
link?

Anyway, JFYI, right now, as at-spi2 works fine now (no crashes), the
current main problem on at-spi2, and severely discussed on the lists
and the hackfest, is the *performance*.

If you take a look to our current GNOME 3 page [1]. Performance is
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mike Gorse | 18 Nov 2010 17:56
Favicon

Re: At-spi over dbus performance.

Hi Luke,

I have just updated http://a11y.org/d-bus, since it was rather out of 
date.  Is this the page that you were looking at, or is there another 
outdated page somewhere?

I have been working on a C-based AT-SPI library to replace the current 
pyatspi2 implementation, so the Python code could become much thinner and 
mainly rely on GObject introspection.  This should significantly improve 
performance based on my testing, and it needs to be done before I can look 
at specific issues.  I have some code in the gi branch of at-spi2-core, 
along with python code that I plan on pushing to a branch of pyatspi2, but 
it is not complete or ready for testing (most AT-SPI interfaces are still 
unimplemented).

Using direct dbus connections should also help.  There is code in the p2p 
branch of at-spi2-atk and pyatspi2 to do this.  I plan on merging this 
into the main branch for 2.91.3; my main reason for not having done this 
already is that it needed the fix for FDO#30574 in dbus-glib, and the fix 
was not committed/part of a release until recently.

Hth,
-Mike

On Thu, 18 Nov 2010, Luke Yelavich wrote:

> Hi all
> I tested at-spi via dbus a couple of days ago, and can certainly notice the performance difference with
some things, and not so much with others. The one area I particularly notice a difference is when reading
the pidgin buddy list with orca. Reading down the buddy list takes a while to speak an individual item, say
(Continue reading)

Permalink | Reply | 2 comments |
headers
Piñeiro | 18 Nov 2010 18:15
Favicon

Re: At-spi over dbus performance.

From: Mike Gorse <mgorse <at> alum.wpi.edu>

> I have been working on a C-based AT-SPI library to replace the current
> pyatspi2 implementation, so the Python code could become much thinner
> and mainly rely on GObject introspection.  This should significantly
> improve performance based on my testing, and it needs to be done
> before I can look at specific issues.  I have some code in the gi
> branch of at-spi2-core, along with python code that I plan on pushing
> to a branch of pyatspi2, but it is not complete or ready for testing
> (most AT-SPI interfaces are still unimplemented).

I think that I already made that question on a weekly meeting, but
just for the record. This work to move most of the current bindings to
C could be used to have a full C-SPI bindings? Or they will be just
the enough code to improve the performance?

BR

===
API (apinheiro <at> igalia.com)
Permalink | Reply | 1 comment |

Gmane