Category: Igalia

Planet Igalia Stuff

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.

    Maemo5 beta SDK is here

    Well, I’m not the first one to say that, as Quim, Joaquim, Berto, Claudio and Dape said that yet, but, hey!, the Maemo5 beta SDK is out ! 😛

    As it was said before, this Maemo5 change a lot the interaction with the user, as it is documented on the HIG Guidelines and on the Hildon Tutorial, oriented to interact with the screen directly, so now we have “touchable widgets” and panning effects. As a example, we have been working on the HildonTouchSelector widget, used to select a value, and in some way, the touchable equivalent to the GtkComboBox.

    Anyway, as Claudio and Berto announced, the big new is that now all the work is done publicly, and now there is a garage project page and a public repository.

    Enjoy! 😉

    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.

    i18n support for vagalume

    There are here on Igalia a lot of people working on Vagalume, a last.fm client started by Berto, another Igalian.

    So, I realize that one missing feature (not a real priority) was the i18n support. So I start to add this, and today, I have finished the support, as you can read on the vagalume developer lists.

    I didn’t made a full translation, only the support (I let the translation for the translators 😉 ) , but you can get something like that:

    There’s no place like home II – FOSDEM

    This weekend I was present at the FOSDEM 2008.

    This is my first “normal day” here at home, as we take advantage of the Monday to visit Bruges

    There was several talks, about several themes, Gnome, KDE, Crossdesktop, etc. Some of them interesting other less. Some of the interesting ones:

    • Mamona (I am still wondering where the name came from, because of the meaning of this in spanish 🙂 )
    • Webkit
    • Gnome Developer Kit: this was interesting, among other reasons, because I didn’t know that this effort exists
    • Clutter: although I was waiting “something new”, he talked about clutter, and some news about that, but nothing to say “wow!”, ie: the only thing Emmanuel Bassi said about Tidy was: “this is a reference toolkit based on clutter”
    • Pigment
    • Desktop accessibility & UI Automation: although Michael Meeks doesn’t talk anything about UI Automation

    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

    Reviving GLSL

    The other day, looking at planet Gnome, I found one more interesting that the others. This was writen by MDK, and its titled Vector drawing: OpenGL shaders and cairo.

    This post continues, in some way, a post written by Tim Janick on his blog, about OpenGL for Gdk/Gtk+, that summarizes some of problems about using OpenGL with Gdk/Gtk+.

    MDK made some tests to compare one an another, I had a little curiosity and check the code. The shader version was written in Cg, and as there are a lot of time that I doesn’t write nothing related to shaders, I decided to waste the little free time I have making the GLSL version of this test this afternoon.

    I same the sames tests, except by environment:

    • AMD 1800+ 784MB RAM
    • Geforce 5900FX 128 MB RAM
    • modified source code (you’ll dont require Cg Toolkit, instead you’ll require Glew)

    And the visual results:


    Cairo bezier


    Cg bezier

    GLSL bezier

    But the most curious was about the times (sorry, not chart this time);

    • cairo: 0,18494 s
    • cg: 0.01927 s
    • GLSL: 0.00155 s

    GLSL better than cg? I suppose that this is the easy answer but:

    • First at all: its too much difference, it has no sense
    • AFAIK GLSL driver compiler its almost the Cg compiler (they use a Unified Arquitecture), you only need to see the extension EXT_Cg_Shader (use Cg code to define a shader object)
    • OpenGL works asynchronously
    • The profile: Cg implementation uses a concrete profile (CG_PROFILE_ARBVP1), GLSL hasn’t got this concept, it tries allways to search the bext vertex/fragment program extension to use.
    • So: the time of only draw some curves its not a accurate (we knowed it before) measure, it is only a guide

    Conclusion: it is good to revive some time GLSL, I need to do this more often, thanks to MDK to give us some code to play !

    There’s no place like home

    At the end, the Guadec 2007 has finished.

    This is my first “normal day” here at home, as we spent all Sunday trying to return from Birmingham to Coruña. This was a little more difficult than expected, including a two-step landing on Coruña (seems that the “typical english weather” that we see these day on Birmingham reach to Coruña).

    After this I can see one phrase: I’m tired. Guadec ES + Guadec sums 12 days flying, living in a hotel, wake up early in the morning, etc. Although I’m sure that people from South America like Germán or Claudio must be very very tired.

    On the Guadec I see a lot of interesting things, a random group of this can be:

    Guadec-ES 2007 died, long live Guadec-2007!

    I have been these last days on the Guadec-ES at Granada. The city was great (although it was really hot).

    The thursday we visit the Alhambra, that, although it didn’t get to be one of the “new seven wonders of the world” it is really great. At the guadec dinner this night, the organization take us to a restaurant on the mount where we see the whole Alhambra. This was great (I’m sorry, I have no photos).

    The friday I had a talk, shared with Juanjo. Here we made a presentation about the Gnome Build Brigade. Iago Toral will have another one, more complete, on the Guadec 2007.

    Another Igalians had presentations too, Juan and Xabier about Webkit and Epiphany, Juanjo and JavierF about TinyMail and a really interesting talk about ringschart made by Alex.

    But, as the song says, “all have his end“, and as we need something to waste our time, after Guadec-es we travel to Birminghan to assist to the Guadec (in a flight with more than a hour of delay, strange no?).

    Today was the first Guadec day, with some interesting talks, how “Latest evolutions in Hildon Desktop”, by Luis Rocha.

    To be continued ….