Category: a11y

Accessibility stuff

Clutter 1.0 released -> Cally 1.0 has born

Today Emmanuel Bassi finally announced the release of Clutter 1.0.0. Great news.

So, for some hours the Cally master didn’t compile against the clutter master. A new branch (cally-0.9) was created (although probably not required), and the master version was updated. As I explain on the README file at Cally, in order to make life easier, the version of Cally is tied to the version of Clutter, in order to avoid questions like “which version of Cally I need to install in order to support Clutter A.B.C?”. So, Cally 0.9.X will grant accessibility support for Clutter 0.9.Y. X and Y will kept independent, for internal usage, in a similar way to GAIL with Gtk+.

In the same way, I started to reduce the awful TODO file, and create some bugs on the clutter bugzilla, in order to trace the missing stuff and bugs in a sensible way. So, since today, Cally has several bugs.

Cally moved to Clutter repository and other news

As some of you already know, at first the Cally git repository was placed on Igalia server, waiting to be moved to the Clutter repositories. As one of the GCDS post-effects, this move was being made. So, the new way to get the Cally source code is:

  • git clone git://git.clutter-project.org/cally

And the development will continue there, so the Igalia one would be closed soon.

In the same way, a new component was added to the O-hand Clutter bugzilla, so now you can open a bug against Cally. Now I will start to transform the über TODO file at Cally in small bugs, in order to track the missing features and other bugs in a sensible way.

I would like to thank Emmanuel Bassi, Ross Burton and Richard Purdie for this move.

Other news:

  • For the people who went to my GCDS talk, I added a branch with the Clutter example I used. This is a heavily modified version of the clutter toy foofone called CrapPhone. This also includes a dogtail script. For the moment it will be maintained as a different branch, as I’m not sure if it is worth to include it with the rest of the examples on the master branch.
  • A first commit related to the AtkText support on ClutterText (CallyText) was pushed on the master, containing the implementation of most of the methods of this interface. It also adds an example (on the examples directory), that tries to use all this methods. This implementation is based on GailEntry, and the methods that still remains are the ones that on GailEntry was based on GailMisc. This library is really tied to Gtk, and some methods are not 100% useful on Cally. Probably a equivalent object (ie: CallyMisc) would be created in order to fulfill this functionality. In the same way, I think that worths to not create über commits, and split this a little. And probably I will start the support for AtkEditableText before finish that.

My last day in GCDS

Like a lot of other fellow igalians, I has been this week on the GCDS (Guadec+Akademy) at the beatiful city of Gran Canaria (beatiful and not as hot as I feared).

Probably I should have made more posts about that, but there were several talks to see, but more important, I used most of my free time to prepare my talk on the GUADEC. This task was scheduled yesterday, at 10:00. Yes, the first talk in the morning. And yes, the day after the sponsored Igalia party 😉 . But in the end there were more people than I expected (although in the same way, I started 5 minutes late by purpose 😛 ).

My talk was about Cally, the Clutter Accessibility Library implementation. In fact we can say that the Tuesday morning was the “Clutter morning”, as there were three talks about Clutter.

Except for the fact that in the middle of the talk the microphone fall to the floor, I think that it was fine. If you are interested, you can download the slides here.

As I said on the talk, currently Cally works, but for a specific scope. So, what about the future?

  • Complete the missing functionality (AtkText: work in progress)
  • Review new clutter-based toolkits (glitter, nbtk, …)
  • Review applications using clutter directly (gnome-shel, …)

Although the GCDS will finish on Friday, this is my last day here (I preferred to go back earlier) . As the song says, “all come to an end“, so I will come back to Coruña tomorrow.

I saw several interesting talks, I met some interesting people and I enjoy all the guadec, but in the same way I’m really tired right now 😉

Cally now with examples

The other day Alberto Ruiz reminded me that several functions on the clutter API have changed, so now it uses floats instead of integers.

Testing it, I notice that this lead to some compile errors on cally, but they were solved easily. However, I take this moment in order to add something more important. I realized that could be hard for anyone to to start to play with the library, as at this moment the cally module requires to be loaded by hand. This issue is documented on the TODO file, but I think that should be better to have some code showing how to do that.

In the same way, I think that for basic development process on cally, it is better to have clutter examples on purpose, instead of working on random existing clutter applications.

So, to solve that, I have added a directory in order to start to put the examples. At the moment it only have one, but at least I have added the infrastructure. The first example is really basic (a stage and tree rectangles), but I was able to detect a bug using it 😛

The compilation of the examples are deactivated by default, but you only need to execute the autogen.sh script adding “–with-examples”, in order to compile them.

CALLY: Clutter accessibility implementation library

During the first months of the year, Igalia has been working on the accessibility support for Clutter, funded by Nokia.

The last weeks we were trying to coordinate how to release it, so I would like to thanks Rodrigo Novo and Quim Gil, in this task.

In the same way, I would like to thank Emmanuel Bassi for the interest he showed in this library, although he is busy enough with the work for the imminent Clutter-1.0.

Using the same scheme for GAIL and HAIL, this library is called CAIL, Clutter Accessibility Implementation Library.
The library was is called CALLY, that is is similar to Clutter + a11y, but avoiding the numbers (ca11y was suggested by Juan A. Suarez, Emmanuel Bassi suggested use “l” instead of “1”).

At this moment the library is really in its beginnings. It is small, and there are a lot of things still to implement, but it works, and allow to expose the different Clutter objects to an AT application. But, it is this moment the best one to start to get feedback from other people, specially from gnome accessibility guys, when we have a working library, but not a huge amount of code really hard to understand as whole.

The first question that arises is if we are approaching this in the correct level of abstraction. Clutter is oriented to be a drawing technology, so in theory the ideal thing should be to implement the a11y support directly on any new clutter-based toolkit. In some way, this is similar to the Gtk+/Gdk relation, and implement a11y support on the Gdk level. It is worth pointing out that because at this level we are mostly missing functional information (objects to interact directly with, like a button), all objects are mostly informative.

But we don’t have news about an hypothetical fancy toolkit (tidy is just an example) and applications are using directly clutter, and probably for a long time, so maybe a direct a11y support will be required, and the work done here could be reused in the future for upcoming toolkits.

But, apart from this philosophical reflections about the existence of CALLY, there are some implementation details that are debatable too (so any feedback is welcome):

  • GtkAccessible equivalent not implemented: the idea was to implement CALLY without modifying Clutter at all. It is enough for the moment
  • Window system information is required to implement AtkComponent, so it depends on the backend
    • For the moment, it only supports the X11 backend
    • There is no implementation done to manage multiple backends
    • An option could be to add the backend support, like Clutter, but then, you need to be sure to install the correct flavor of CALLY with the correct flavor of Clutter.
    • Other option to ensure a synchronization between Clutter and CALLY could be to compile both together, and integrate CALLY as a Clutter module, like GAIL on Gtk.
    • After a fast review of SDL I didn’t find a way to implement AtkComponent properly. Is it viable on any backend?
  • Textures as buttons
    • ClutterActor has signals for “press” and “release”
    • Any actor could be used as a button; the most used one is the ClutterTexture
    • So the role should be different, ATK_ROLE_IMAGE==>ATK_ROLE_BUTTON, and the app should change that. The current experience is that they will not (or at least not easily).
    • Solution: change it on initialization if we detect that it has a handler bound to these signals.
  • AtkAction implemented on CallyActor
    • As ClutterActor has signals for “press” and “release”, it makes sense to implement AtkAction on CallyActor
    • So we should find a way to extend AtkAction implementation on subclasses
    • Used the solution implemented on GailCell
    • Maintain a list of action functions, and add a public API on CallyActor to add/remove that.
  • ClutterContainer
    • AtkObject uses a composite pattern. On GAIL GailContainer redefines these methods.
    • On Clutter ClutterContainer is an interface, so several Clutter object could implement it
    • Several AtkObject methods can be implemented in behalf of ClutterContainer.
    • So currently, the implementation of these methods on CallyActor is conditional. On runtime, it checks if the Clutter object implement this interface
  • The interaction with GAIL is not clear. Or with other words: the a11y support for applications using Clutter and Gtk+ is not clear yet
    • The existing a11y support for GtkClutterEmbed was not included, as was based on the assumption that the environment will be always using this widget
  • CALLY is using a module approach like GAIL.
    • Currently the applications are required to load this module by hand
    • With GAIL you load it by using GTK_MODULES=gail:atk_bridge
    • But there isn’t (AFAIK) CLUTTER_MODULES
    • Anyway it is not clear if this could be the best option, as GTK_MODULES is causing some problems in other environments

    An of course, a lot of missing functionality.

    You can read a detailed list on the TODO file I included in the source code.

    At this moment the code is in a public Igalia git repository. The idea is to move it someday to the clutter repository, but at this moment Emmanuele Bassi and other Clutter developers have a lot of work with the imminent Clutter-1.0 release, so we will try to improve CALLY meanwhile.

    So, if you are interested, you can get the code here:

    git clone http://git.igalia.com/cally.git

    Update: After the Ron Thompson comment, the library was renamed from cail to cally. Sorry for the nuisance.

    More about GAIL

    In one of the old bugs related to GAIL you can find that:

    “In general we don’t want to export the other gail headers, since the implementation details of how ATK is provided for specific widgets is not something we want to require bincompat for, nor do we want these interfaces, in general, to be used externally (other than the ones in libgail-gnome).”

    This sounds pretty well. Anyway, this paragraph has a “but”. The reporter (Bill Haneman, one of GAIL’s fathers), opened the bug in order to make public the GailWidget header, as it is a real useful class.

    On one of my previous posts, I said that although you have an anonymous (run-time) inheritance from GAIL, this can’t solve the problem that without the header you can’t redefine the virtual methods of a GAIL object without reimplement it, or make something really hackish.

    Well, now I found another problem with this: GtkAdjustment. The a11y support on GtkAdjustment is implemented on the object GailAdjustment. But as you normally don’t require direct a11y support for this widget, this class is used as an aux class for classes like GailRange (GtkRange). Soooo, in the end, the current implementation of GAIL doesn’t define a concrete GtkAdjustment factory.

    Conclusion: if you want to use GailAdjustment outside Gtk+, you can’t do that using the “indirect subclassing method”, so if you want that, you need to reimplement it, or just C&P the code. And this is funny, because normally with the C&P anti-pattern you get two similar problems fixed with two similar solutions (the original code and his copy). In this case, with exactly the same problem, you get two similar (equal) solutions (the original and his copy).

    Random thoughts about a11y on clutter

    Clutter and a11y support are important issues related with Gnome, so it is normal that sometimes the question “a11y and Clutter” arise. Some time ago this appears on the desktop devel list, and Emmanuel Bassi closes says that there are a plan for it in the future [1]

    And now, this topic has return, this time on the clutter mailing list [2] [3]

    Some time ago I was playing with this two topics, and I made some coding tests too. As this codings tests are still too basic, here [4] is a link to a pdf with my first thoughts after this implementation, so anyone could read about it if he wants.

    Playing with GAIL

    These past weeks I have spent some time taking a look to GAIL, the Gnome Accessibility Implementation Library, taking a look at the gnome accessibility guides, and to an interesting framework related to that, dogtail ( it will be cool to make GUI testing for fisterra, eh? :P).

    I took a litle to the code and play a little with it. One of the things you can see is that almost all the interfaces are private (the headers are not installed with the library). So if you make a custom subclass of any gtk widget you haven’t got access to his accessibility object to extent. But you don’t don’t have to reinvent the wheel, as there are a way to workaround it, as you can do an anonymous (run-time) inheritance from GAIL.

    Ok, so, no problem no? Well, I don’t think so (IMHO). With this solution you can obtain the parent type, and extend it using g_type_register_static. But, what happens if you have an abstract class, with any virtual abstract functions? In theory, the concrete subclasess requires to implement this functions. But how can do that if you haven’t got the parent definition (on the header)?

    You can think: but it is unlikely to happen. Well, this is not very common, but it happens: GailRendererCell define two virtual elements: property_list and update_cache. This add the accessibility for GtkCellRenderer. This has some subclasses, that defines it: GailTextCell, GailBooleanCell and GailImageCell.

    IMHO it is really common to make a GtkCellRenderer subclass, as you could want a custom cell rendering. So, what happens if you want to create a custom library with widgets (or something similar), and some try to extent it? How do you redefine this virtual elements?

    You could do some hacks, like use directy the gail source to access to the libraries (it is free software, you know? 😉 ), or create a custom header with the structures you require to redefine it. But this last is a really dirty hack, in fact, a copy&&paste hack, with all problems of sync, and others related with the anti-pattern copy and paste.

    Conclusion: in my opinion, the gail interfaces, or at least some of them, should be exposed

    Well, I have found other “particularities” on gail code, but this can be exposed on the next post