Re: Accessibility module loading

[Marc Mulcahy <marc mulcahy sun com>]

Or possibly, in keeping with the idea of splitting individual library 
support into separate libraries, the split should be:

libgail: module with general accessibility related functions and utils 
useful to implementors
libgail-gtk: GTK+ specific GAIL implementation

Marc

At 02:25 PM 12/14/2001 +0000, Padraig O'Briain wrote:
> 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
>
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list