[Kde-accessibility] Re: Qt and accessibility on Unix

[Bill Haneman]

On Mon, 2002-12-02 at 20:31, Pupeno wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I think that this shows that the dynamically loaded (at run-time) library 
> (a.k.a plug in) can't be avoided in the context of unix accessibility 
> (atk/at-spi).

This needn't be a "plug-in" in the usual sense of the word. 

You can of course link to ATK (hard dependency) which is a small
interface-definition library, which is what GTK+ does.  Then "ATK" is
the lingua franca that your "plugin" speaks.  

But certainly I would recommend using libraries dynamically loaded into
the applications' process space as a means of implementing the bridge;
you really don't want multiple RPC/IPC mechanisms as I have said
before.  ATK isn't an RPC mechanism because it isn't remote ;-), ATK
works within the application's process space.

So you will be using dl_open or something like it somewhere in your
solution, for sure.  

-Bill

> Thanks.
> On Monday 02 December 2002 15:18, Bill Haneman wrote:
> > On Mon, 2002-12-02 at 19:32, Volker Hilsheimer wrote:
> > ...
> >
> > > We have to check this on other systems as well; in general I think a
> > > lightweight and generic interface between toolkit and infrastructure
> > > makes more sense than pulling heaps of dependencies into either of them,
> > > esp. if those dependencies are not unlikely to make trouble on e.g.
> > > commercial Unix platforms - if commercial Qt doesn't build due to
> > > what-do-I-know with accessibility support configured we help nobody. We
> > > have enough trouble with dependencies to other 3rd party libraries
> > > already (including C libraries).
> >
> > So far I think the only library that has been seriously suggested there
> > might be a build-time dependency on would be glib; and possibly this
> > dependency would be restricted to a dynamically loaded KDE accessibility
> > module, plugin, or the like.  Thus the core of KDE could continue to
> > build and function whether the external libraries and bridges needed by
> > accessibility were present or not.
> >
> > So fortunately there are three or more kinds of dependencies, including
> > build-time, runtime, and conditional;  a conditional dependency might
> > for instance only be incurred if accessibility were requested at
> > runtime.  (I don't think anyone is pushing for additional "hard"
> > (non-conditional) build-time or runtime dependencies for KDE in the
> > current discussion.)
> >
> > In the case of GTK+ we allowed GTK+ to have a hard dependency on ATK,
> > but not on the implementation code which we externalized in dynamically
> > loaded modules.  Likewise our dynamically loaded bridge code had
> > dependencies on ATK and AT-SPI, CORBA, etc. but these dependencies were
> > totally isolated from and invisible to the running application, and
> > since these modules were optional, applications run normally without
> > them.
> >
> > regards,
> >
> > Bill
> >
> > > All this is of course something that need to be evaluated at some point.
> > >
> > > --
> > > Volker
> > >
> > >
> > > _______________________________________________
> > > kde-accessibility mailing list
> > > kde-accessibility@mail.kde.org
> > > http://mail.kde.org/mailman/listinfo/kde-accessibility
> >
> > _______________________________________________
> > kde-accessibility mailing list
> > kde-accessibility@mail.kde.org
> > http://mail.kde.org/mailman/listinfo/kde-accessibility
> 
> - -- 
> Pupeno: pupeno@pupeno.com
> http://www.pupeno.com
> - ---
> Help the hungry children of Argentina, 
> please go to (and make it your homepage):
> http://www.porloschicos.com/servlet/PorLosChicos?comando=donar
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
> 
> iD8DBQE968MYLr8z5XzmSDQRAvoiAJ9BgeQuV3v3mLUHdDE6Yg20W59QpgCg42eN
> sISXIMt0uLcypDsdI45K/0s=
> =9pXA
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> kde-accessibility mailing list
> kde-accessibility@mail.kde.org
> http://mail.kde.org/mailman/listinfo/kde-accessibility