Patrick Welche | 19 Apr 18:52 2014

a11y bus trouble after upgrade

I have been upgrading eg dbus, glib, at-spi2-core etc. and now registryd
won't start. The best test so far, which is I think what
get_accessibility_bus_address_dbus() does in at-spi2-core atspi-misc.c is:

  dbus-send --print-reply --dest=org.a11y.Bus /org/a11y/bus \

which returns:

  Error org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.a11y.Bus exited with status 1

This suggests that the session bus is running sufficiently to accept a
connection, but then something fails - any clues on how to find out what?


Mike Gorse | 15 Apr 00:32 2014

ANNOUNCE: at-spi2-atk 2.12.1 released

At-spi2-atk 2.12.1 is now available for download at:

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 C and a wrapper
for Python.

What's changed in at-spi2-atk 2.12.1

* Clean up socket directories on exit (bgo#684076).

Where can I get more information about AT-SPI2

The project wiki is available at:

How can I contribute to AT-SPI2?

We need help testing with Gnome accessibility technologies, improving
performance, and generally tying up loose ends.  The above-referenced page
(Continue reading)

Samuel Thibault | 3 Apr 00:10 2014

[Extended call] Accessibility and mobility topic of LSM 2014


The call for talks for LSM has been extended up to 15th April, please
consider submitting talks!


                 15th Libre Software Meeting
                      July 5-11, 2014
                     Montpellier, France
              Call For Papers and Participation
         limited to accessibility and mobility topic
     [we apologize for duplicate receipt of this message]
         Last call before deadline : april *15th* 2014

Sharing of knowledge, freedom of information, community spirit,
exchange of ideas, technological progress: every year the Libre
Software Meeting (LSM) follows the Libre philosophy.

RMLL/LSM is a non-commercial series of conferences, round tables
discussions and practical workshops based on Libre/Free Software and
its uses. Its aim is to provide a platform for Libre/Free Software
users, developers and stakeholders.

Access to LSM is free of charge and open to everyone. The conference
will be held in Montpellier from July 5 to July 11, 2014.

(Continue reading)

John Emmas | 27 Mar 12:38 2014

Version 2 numbering

Hi guys,

I'm a bit confused about the "version 2" numbering for libatk.  I 
noticed this morning that a new branch got created for version 3 (the 
new branch is called "gnome-3-12") and I assume that it's timed to match 
similar libraries (such as glib / glibmm etc) who also just released 
version 3.12

However....  the latest atk branch I can find for version 2 is 
"gnome-2-30" - even though glib and glibmm are now 5 x releases further 
on, at ver 2.40.  Glib and Gtk seem to be developing versions 2 and 3 in 
parallel.  Is that not the case for atk or is there some other 
explanation for why the version 2 branches haven't moved on since 2.30?  
It's not a big problem.  I'm just curious to understand the difference.  

Magdalen Berns | 17 Jan 01:40 2014

GNOME Accessibility Mailing Lists

Hi lists,

Sorry for the cross post but this concerns both lists:

gnome-accessibility-devel [1]   

gnome-accessibility-list [2]

Both seem to be described as GNOME accessibility development or
technical discussion lists.

It does seem appropriate to provide a means for users to access support
from developers (and other users) but a bit less appropriate to subject
non-technical users to development threads in the process. So, it might
be a nice idea to:

a) move developer/technical discussion to gnome-accessibility-devel    

b) redefine gnome-accessibility-list as a list for users of the tools
and place to access support in using them instead of a development list.

What do people think about this?


magpie | 9 Jan 18:00 2014

[Fwd: Mousetweaks: integrate into GNOME Shell or keep in its current form?]

Happy 2014 everyone,

I thought I'd sent this last week but it came up in the a11y meeting 
today that the email was not in archives so I am resending and hopefully 
this finds everyone well. Further to that I am actually going to cross 
post to the GNOME Shell list (I was not sure whether to do that last 
week so did not) as Alejandro pointed out it is a decision for both 
mousetweaks developers and the GNOME Shell team to make so hopefully 
they will not mind the cross post! I added point 6 but have left the 
rest as it was.

I am bringing the following thread up:

It seemed to fizzle out with nothing decided and am hoping to finding 
out what people and hopefully Gerd and Francesco (the mousetweaks 
developers) are thinking now that some dialogue has happened. It would 
be good to find out what can be done for the feature. A few of 
points/questions/concerns on this:

1. I posted this out to both GNOME Shell and a11y lists first off 
(reluctant to keep doing that but feel free to forward this on anyone 
who thinks to do so) yet seems to have been very little comment from 
general group of gnome-shell developers. Will gnome-shell actually want 
this? I am less sure since I have tried quite a few times to get 
Mousetweaks in the menu for this 5 year old bug: and the response so 
far has not seemed very encouraging.

(Continue reading)

Magdalen Berns | 21 Nov 01:18 2013

Mousetweaks: integrate into GNOME Shell or keep in its current form?

Hi all,

Sorry for the epic email. I was speaking to mclasen and halfline about
the mousetweaks discussion I started in a private email thread with the
MT developers Gerd and Francesco and, rather than ccing people at random
intervals it seems more appropriate to forward to the gnome-shell and
accessibility lists so others can comment!

Hope the thread below makes sense, but just to summarise the discussion
it is about whether or not to build Mousetweaks into GNOME Shell as
there were a couple of of considerations which need to be thrashed out
before a decision can be arrived at. 

Unfortunately I had to paste the thread from different parts or bits
would have got missed so let us know if there's anything too confusing
to figure out from the text below and I can try to help.


Magdalen Berns <magdalenberns <at>>
22 Oct
to Gerd, Francesco
Hi Gerd, Francesco,

How are you both doing? I wonder if you got my email about mousetweaks a
while back? It may have got lost in the lists.

(Continue reading)

Mike Gorse | 17 Dec 12:59 2013

ANNOUNCE: AT-SPI 2.11.3 released

AT-SPI 2.11.3 is now available for download at:

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 C and a wrapper
for Python.

What's changed in AT-SPI 2.11.3

* Fixed atspi_text_get_bounded_ranges.

* Document: add current page and page count properties (BGO#719508).

Where can I get more information about AT-SPI2

The project wiki is available at:

How can I contribute to AT-SPI2?
(Continue reading)

Piñeiro | 17 Dec 10:23 2013

ATK 2.11.4 released

About ATK

GNOME provides support for accessibility devices using the ATK
framework. This framework defines a set of interfaces to which
graphical interface components adhere. This allows, for instance,
screen readers to read the text of an interface and interact with its
controls. ATK support is built into GTK+ and the rest of the GNOME
platform, so any application using GTK+ will have reasonable
accessibility support for free.

Nonetheless, you should be aware of accessibility issues when when
developing your applications. Although GTK+ interfaces provide
reasonable accessibility by default, you can often improve how well
your program behaves with accessibility tools by providing additional
information to ATK. If you develop custom widgets, you should ensure
that they expose their properties to ATK.


* AtkRole:
  * Bug 720065: add roles for description lists
* Deprecations:
  * Bug 476674: deprecate table properties that depend on the
    row/column number
  * Bug 652798: kill AtkMisc
  * Deprecate connect/remove_property_change_handler
  * Deprecate atk_role_register
* Documentation:
(Continue reading)

Alexander Surkov | 11 Dec 18:15 2013

new states for meter element


HTML5 introduced meter element [1], which is basically a progressbar role but can be in special states:

1) optimal state when value is in optimal rage  (for example, if  low < optimum < high then value should be in [low, high], if optimum > high then value should be greater than high.

2) suboptimal state when value is in range next to optimum range (for example, if low < optimum < high then value < low is suboptimal.

3) subsuboptimal state when value is not neither optimal nor suboptimal for example if optimum > high but value < low.

Firefox colors these states as green/yellow/red.

Would it be reasonable to introduce these states in ATK? Any other ways to expose that info?
gnome-accessibility-devel mailing list
gnome-accessibility-devel <at>
Piñeiro | 5 Dec 17:45 2013

ATK: solving the multi-toolkit environment with an API and not with implementation hacks

Hi, sorry for the cross-posting, but as this affects the main toolkits
on GNOME, I also would like to have their input.


AtkUtil and current hacks to avoid it being overrided sucks. In fact, in
some cases, we don't even have hacks, so gnome-shell accessibility under
Wayland is broken. We need a better API.

Long explanation:

The idea behind ATK was being an abstraction of UI elements using common
accessibility terms. In that aspect, ideally you only want to have an
object that represent a UI element and some info. Additionally
accessible tools need some extra global functionality, like mouse
tracking or consume keystrokes. But as we already have a global daemon
bringing all the accessible information and functionality, the at-spi2
daemon, ideally2 we would like to get that information from this daemon.
On X, at-spi2 tried to get all the information from there. In short, ATK
being a server-side library, and atspi being a client-side library. But
although that is the ideal situation, the real situation is that some of
the functionality needed to be provided by the toolkit (so from the
application) itself. Specifically global keystroke listening. To make
this worse ATK was designed with the idea of one-toolkit/implementation
for application. All this mixtured in a rush led to the horrible AtkUtil
API, that toolkits needed to implement, but you only can have one
implementation to rule them all. That means that on situations with more
of one toolkit, it was needed to add several hacks to ensure which
implementation do you want, because implementations needs to override
previous defined implementations of AtkUtil (hacks added due Firefox).

Since I become ATK maintainer, AtkUtil has started to be more and more
smaller. Some of his methods were deprecated, and others were
implemented by ATK itself, so toolkits need to implement less and less.
My hope was being able to get rid of it eventually. Especifically, I
hoped that Wayland would provide a way to listen/consume key events
globally, without the need of toolkits providing it, so moving that to

At the same time, knowing from which toolkit each accessibility object
came became relevant. This is because in short, the behaviour under each
environment can be different, and is not possible to hide it just with
an abstraction. For example, dealing with epiphany, for Orca is relevant
to know if an object came from gtk+ (the menus, etc) or from webkit
(from the html content itself). As ATK only provides one point to expose
the toolkit, the hacky solution was ask implementors to expose the
toolkit via an attribute on the atk object [5][6] (attributes are a
general way to expose custom information from an accessible). Something
that is confusing. So as I say on this bug [2][3], I would like to add a
method to AtkObject and deprecate global AtkUtil get_toolkit.

Doing that, there would be only two things that prevents to kill AtkUtil:
  * Accessible root object
  * Global key event listener

The root could be solved by just adding a method on at-spi2-atk to
specify which is the root object. And, as I said I hoped to be able to
remove the global key event listener too.

*The problem*

1. Getting a solution for the key stroking on X has shown to be more
complex that thought. And more important, it seems that it will be also
the case for Wayland. Taking into account what Matthias Clasen told us
during Montreal summit and on this email [1], on Wayland that will be
the case, at least on medium term. So that functionality would need to
be provided by implementors for a while.
2. Right now on Wayland, gtk AtkUtil implementation is overriding
clutter AtkUtil implementation, so gnome-shell is inaccessible under
wayland [4]. The fact that were working before was merely luck, as
clutter_init was called after gtk_init. It seems that on wayland the
order is the opposite. And of course, there is the possibility of
stopping to work under X.

In the end toolkits need to provide some toolkit-side unique
functionality, and as we can be in a multi-toolkit environment, we also
need a way to specify which one we want.

*The proposal*

Initially I thought on this:
  * Define a new class, AtkToolkit. Basic functionality, get root object
and global key event listener.
  * Add a new method on AtkUtil that allow to register toolkit objects.
  * Add a method on AtkUtil to retrieve registered toolkits and specify
which AtkToolkit you want to use.
     * get_root and global_key_event_listener on AtkUtil will be
reimplemented, in order to delegate on the active toolkit object
  * gtk+ would create their own subclass of AtkToolkit, create one
object and register it. Clutter would do the same. gnome-shell will
specify which one will be the active.
  * AtkObject would have some methods to retrieve from which toolkit it
comes [4]
     * AtkUtil get_toolkit_name/version will be deprecated.

All that would solve the situation. The problem with this proposal is
that there are "too many toolkits" here. From one side we have one
Toolkit object that provides some specific functionality, and has a kind
of global meaning. From the other side, we have a method for each object
to retrieve the specific toolkit name/version. And that this could leave
to confusion. I guessed if that could be solved by just using a
different terminology. So keeping atk_object_get_toolkit_name, but
rename AtkToolkit to AtkImplementation. Or the opposite (as suggested
here [3]). What I really want to avoid is something called "Util" and
being one of the most important pieces of the library.

In any case, there is a chance that the proposal itself can be improved.
Comments, suggestions, thoughts?




Alejandro Piñeiro

clutter-list mailing list
clutter-list <at>