Re: Accessibility module loading



There is some utility-type code in GAIL which might be useful to accessibility 
implementors. I am thinking that perhaps libgail should be split into two parts:

1) libgail, the GTK_MODULE which contains the accessibility implementations for 
GTK+ widgets

2) libgail-util, which contains code which implementors of accessibility support 
on other objects might find useful

Padraig

> 
> 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
> > 
> 
> _______________________________________________
> gnome-devel-list mailing list
> gnome-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-devel-list




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]