Re: Accessibility module loading



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




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