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