[g-a-devel] About making public gtk accessibility headers

[Piñeiro <apinheiro igalia com>]

The conclusion of a recent thread was discuss gtk technical stuff on
this list, so I will do that instead of creating a bug.

Background: at the end of the GUADEC we had a BOF/Camp about
accessibility [1]. During one of those days we were taking a look to
evince. Although evince accessibility support is still a work in
progress, some months there was something working, and now nothing is
working.

The reason is some of the lately changes on gtk3 in relation of how to
specify the accessibility class to a specific gtk class. In the old
times the way to specify it was using factories [4]. Factories were used
to set the type of the accessibility object, and also to get the type of
the parent accessible object. Something that (perhaps) made sense on a
environment were the ATK implementation was in a plugin. These days that
is not true anymore. ATK implementation for GTK are included on GTK.
After the last changes on gtk, gtkwidget saves the accessible_type to
use on each class, so in order to specify what it is the type that you
want to use is as easy as call gtk_widget_class_set_accessible_type at
the class_init. So, what is doing gtk_widget_get_accessible?:

  * If you have a valid accessible type at the widget class, use it to
instance the accessible object.
  * If the accessible type at the widget class is GTK_TYPE_ACCESSIBLE,
it tries to use the factories.

The second one is something like a fallback. But that fallback is
failing. The example is evince. They have a custom widget, EvView,
subclass of GtkLayout. Until now evince was using the factories to
specify EvViewAccessible as the type to be used to instance EvView
accessible object, and also in order to get the type of the accessible
object assigned to GtkLayout.  But the accessible type is already is
already assigned (at GtkContainer class_init). So the factories are not
being used on EvView->get_accessible.

So, the obvious solution could be use
gtk_widget_class_set_accessible_type on EvView. But the problem is that
the headers for the accessibility objects on gtk are not public (in
fact, if you take a look to gtk/a11y get_type methods has a '_' prefix
so we assume that they are private). Probably we could keep doing some
kind of hack to obtain the parent accessible type. But remember that we
are talking about hacks like the ones on link [2] and specially link [3].

IMHO, the best solution would be making public also the accessibility
headers, so any third-party doing custom widgets could use directly the
types of those classes to extend, and just one line to specify the
accessibility type. Take into account that evince are not the only one
affected. Any application defining custom widgets are also affected.

I also don't see the API of those headers changing a lot, as most of the
functionality is defined on ATK interfaces (although something like
adding pads on those could be sensible). The only possible problem could
arise if we decide to add an accessible class in the middle of two
existing classes (like a new gtkbinaccessible in the middle of current
gtkcontaineraccessible and gtkbuttonaccessible), as the parent class
could change. But I see that unlikely at this moment.

Finally, take into account that clutter is already doing that. Cally
(clutter ATK implementation, that still uses factories, but eventually
they will be nuked) is public, so St at gnome-shell is free-factory.

Opinions?

BR


[1] https://live.gnome.org/Accessibility/BoFs/A11yCamp2012
[2]
http://projects.gnome.org/accessibility/talks/GUAD3C/making-apps-accessible/anonymous-inheritance-1.html
[3]
http://projects.gnome.org/accessibility/talks/GUAD3C/making-apps-accessible/anonymous-inheritance-2.html
[4] http://developer.gnome.org/atk/stable/AtkObjectFactory.html

-- 
Alejandro Piñeiro Iglesias