Re: Accessibility module loading

["Padraig O'Briain" <Padraig Obriain sun com>]

Michael,

My ambition is that GAIL will not export any API and that nothing will depend on 
GAIL. 

I am attempting to implement support accessibility suuport got gtkhtml2 on this 
basis. I have identified some additions to the ATK API which I need for this, 

1) Ading atk_object_factory_get_accessible_type () which returns the GType of an 
accessible which the factory creates.
2) Adding a class which creates an accessible for an object which derives from 
GObject. This is not necessary but would save wheel reinvention when it is 
desired to associate an accessible with something which is not a GtkWidget; 
GnomeCanvasitem and HtmlBox are examples.


Padraig

> 
> 
> Hi Padraig,
> 
> On Fri, 14 Dec 2001, Padraig O'Briain wrote:
> > I take the view that accessibility support should not be an add-on but
> > the accessibility support for a widget should be in the same library
> > as the widget.
> 
> 	I personaly think this is a mistake, I am not convinced that the
> (huge: a new API per new widget in Gnome ultimately) gail API should be
> frozen and exposed to the public.
> 
> 	I have a growing convinction that we need to be able to expand and
> modify the gail APIs in future - and of course, this we cannot do if every
> core Gnome library is using them.
> 
> 	This contrasts with the proposal I have put forward, which would
> allow gail's modules to be demand loaded - and accessibility support for
> the gnome platform to be implemented inside a limited number of purely
> accessibility related modules - thus splitting the dependency tree and
> minimizing any Accessibility API impact.
> 
> 	Given that it will have a relatively minimal performance impact -
> I can see virtualy no disadvantages to bifurcating the dependency tree and
> pulling a new, massive, untested API out from the bottom of the pile. eg.
> it is not really reasonable to make libgnomeui depend on gail IMHO. It
> would be ideal to keep this API private.
> 
> 	So - here is what I suggest.
> 
> 	We guard all the installed gail headers with:
> 
> #ifdef GAIL_PRIVATE_API_DONTUSE
> #endif
> 
> 	And since people want to leave gail at the bottom of the build
> dependency stack [ fair enough ], we create another module say
> 'gail-gnome' higher the build dependency stack [ that depends on
> libgnomeui, eel, etc. ] and that installs:
> 
> 	libeel-a11y.so
> 	libgnomeui-a11y.so
> 
> 	etc. and we dynamicaly link them in automaticaly via the proposed
> hooks.
> 
> 	This has the advantage that the gail API is a shared, private
> contract between 'gail' and 'gail-gnome' and thus it can be altered
> substantialy affecting only two packages. Clearly in the future when we
> are 100% happy with exposing that volume of API - and it has been well
> tested and shaken down it makes sense to expose gail to everyone.
> 
> > If we took this view the only thing we would lose is the ability to
> > dynamically change accessibility support.
> 
> 	We will still need this; since there will be a performance impact
> (however minor) to accessibility support - and we don't want to push that
> on all our unimpaired users IMHO.
> 
> 	Does that explain the rational some more ? I would be rather
> disturbed if you were to unexpectedly come out with the expectation that
> libbonoboui, libgnomeui etc. were intended to depend on gail in the build
> order.
> 
> 	Regards,
> 
> 		Michael.
> 
> -- 
>  mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot
>