Re: Accessibility module loading

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

Marc,

I do not think that it affects your proposal but I am strongly of the opinion 
that accessibility support for a library should be part of that library, not in 
a separate library.

Padraig

> X-Sender: mm128299 bes central sun com
> To: "Padraig O'Briain" <Padraig Obriain sun com>, michael ximian com
> Subject: Re: Accessibility module loading
> Cc: bill haneman sun com, andersca gnu org, gnome-devel-list gnome org, 
gnome2-release-team gnome org, gnome-accessibility-list gnome org
> Mime-Version: 1.0
> 
> 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
>