|
On 08/07/2012 03:17 PM, Matthias Clasen
wrote:
If currently you mean after last changes on gtk accessibility implementation done during February (that improved a lot the status of that implementation) then yes, it is true. If currently means 6 months ago (or since 2001 to 2011), then no, it is false. gtk atk implementations were private, but they were subclassable from the outside. That was one of the reasons of all that registry/factory thing at ATK. Being possible to access somehow to the parent accessible type that resided on a plugin (so implementation was private). That hack was called anonymous inheritance. As I noted on the initial mail of this thread, more info here [1] Can you explain why that is a problem ? Well, subclassing means that you inherit the code from your parent, and that you change or add code if something if different. But for part of that code, that modification is not required. Being able to reuse the code implemented on your parent class is one of the advantages of object oriented programming. In the evince specific case we have something like this (some intermediate classes removed for simplicity): gtkwidget /\ || gtkcontainer /\ || evview Privately on gtk+ we have: gtkaccessible: /\ || gtkcontaineraccessible gtkaccessible implements some AtkObject methods, and some atk interfaces, like AtkComponent (related to position and size). gtkcontaineraccessible implements some container-children related AtkObject methods based on gtkcontainer API. As gtkaccessible is public, EvViewAccessible could be a direct subclass of that. That would mean that all the AtkComponent implementation are there, so EvViewAccessible doesn't need to reimplement it again. But if it do that, it will require to implement again those container-children related AtkObject methods based on gtkcontainer API. It can do that, as EvView is a GtkContainer, but in the end it will be repeating the code. And this is just an example. In general each accessible class will implement ATK interfaces, and part of those implementations will be valid to any subclass. Anyway, yes, technically it is true that there are one extra option: d) Keep gtkaccessible as the only public one, so third party applications will require to reimplement the ATK interfaces or the accessibility support for their custom widgets. Option that in my opinion, will lead to tons of C&P code from gtk+ on those third party applications. BTW. At this moment we can't implement d) directly using gtk_widget_class_set_accessible_type at this moment. As it is said on his documentation [2] "The given type
must be a subtype of the type used for
accessibles of the parent class.
". GtkContainer class_init will set the accessible type to
GTK_TYPE_CONTAINER_ACCESSIBLE. So if we want to use
set_accessible_type to set the proper type for ev view, that
EvViewAccessible type needs to be a subclass of
GtkContainerAccessible.BR [1] http://projects.gnome.org/accessibility/talks/GUAD3C/making-apps-accessible/anonymous-inheritance-1.html [2] http://developer.gnome.org/gtk3/3.5/GtkWidget.html#gtk-widget-class-set-accessible-type -- Alejandro Piñeiro Iglesias |