[Kde-accessibility] Use of gconf key '/desktop/gnome/interface/accessibility' on KDE ?

[Ashu Sharma]

On 6/26/06, Bill Haneman <Bill.Haneman at sun.com> wrote:
>
> Hi Ashu:
>
> Currently the state of KDE accessibility is somewhat limited.  Other
> than some important theming and keyboard-navigation support, which does
> not require a complex interface such as AT-SPI, there are only a few
> useful utilities like KMag, KMouth, and KMousetool.  While these are
> nice utilities, they aren't enough to allow users who cannot use a
> keyboard at all, or who are blind or have very limited vision, to use
> KDE.
>
> We have three working screen readers (for blind users) for the free
> desktop now; gnopernicus, orca, and LSR.  For users who cannot use a
> keyboard, we have GOK and Dasher.  All of these technologies require the
> full power of the AT-SPI interfaces, and thus require the ORBit2 CORBA
> stack in order to work.  The gconf key you mention is for determining
> whether support for such full-features assistive technologies should be
> enabled or not.
>
> When KDE/Qt applications provide full-featured accessibility services,
> as is planned for Qt4, then those services can be bridged to AT-SPI,
> making those applications available to screen readers and other sorts of
> "user interface adapting" assistive technologies.
>
> While it would be possible to write a "KDE" screen reader or KDE
> onscreen keyboard for severely disable users (for instance users who
> cannot even 'point and click' reliably), I don't think it would be the
> best use of our resources.  Technologies like Orca are intended to work
> with AT-SPI-enabled KDE apps just as they work with applications like
> OpenOffice, Java apps, Firefox, and other applications today, not just
> "gnome".  By writing Orca scripts for popular KDE applications, the KDE
> desktop, and by fixing the inevitable bugs in KDE's keyboard navigation
> and accessibility support, a modest amount of development effort can go
> further to benefit disabled users.
>
> best regards
>
> Bill
>
> On Mon, 2006-06-26 at 13:30, Ashu Sharma wrote:
> > On 6/26/06, Bill Haneman <Bill.Haneman at sun.com> wrote:
> >         On Mon, 2006-06-26 at 08:19, Ashu Sharma wrote:
> >         > Hi,
> >         >
> >         > There was discussion about making use of ATK on KDE, rather
> >         than
> >         > putting in another CORBA implementation to talk to AT-SPI
> >         (to avoid
> >         > dependency on GNOME-related libraries). I'm not quite clear
> >         as to what
> >         > was finally decided.
> >
> >         If KDE writes to ATK, it makes the job easier in a number of
> >         ways (at
> >         the cost of introducing a glib dependency, but hiding other
> >         gnome-ish
> >         dependencies).  However, the AT-SPI layer requires CORBA in
> >         order to
> >         function, so in order to actually expose useful information to
> >         our
> >         assistive technologies, an application must LD_PRELOAD the
> >         "atk-bridge"
> >         module which bridges from ATK to AT-SPI's CORBA IPC.
> >
> >         I think this is the most effective thing to do for the time
> >         being
> >         (preload atk-bridge), since it doesn't introduce a CORBA
> >         dependency on
> >         the KDE apps (only a soft runtime dependency).  The AT-SPI
> >         assistive
> >         technology clients cannot work without the AT-SPI/ORBit2/etc.
> >         libraries
> >         being present on the system anyhow, so from a practical
> >         perspective this
> >         is the minimum current dependency situation.
> >
> >         There's another environment variable you can look for if you
> >         don't want
> >         to use gconf; GTK_MODULES.  Of course that's still quite a
> >         gnome/gtk+-ish variable and arguably not appropriate to KDE
> >         anyhow, so
> >         it might be cleaner just to spawn a gconf-client executable
> >         and parse
> >         the output, in order to detect whether assistive technology
> >         support is
> >         desired or not.  Also, soon there will be a slightly different
> >         mechanism
> >         for detecting the presence of the AT-SPI registry - it will
> >         place an IOR
> >         as an Xatom on the root DISPLAY window.  This means you can
> >         find it
> >         without using bonobo-activation.
> >
> >         regards
> >
> >         Bill
> >
> >         >
> >         > On a related note, is the gconf
> >         > key '/desktop/gnome/interface/accessibility' used on KDE
> >         too, to set
> >         > or find if accessibility support is to be enabled on a
> >         system? Or, is
> >         > it used only on GNOME?
> >         >
> >         > Thanks,
> >         > Ashutosh
> >         >
> >         >
> >
> ______________________________________________________________________
> >         > _______________________________________________
> >         > kde-accessibility mailing list
> >         > kde-accessibility at kde.org
> >         > https://mail.kde.org/mailman/listinfo/kde-accessibility
> >
> >
> >
> > Bill,
> > Thanks for these details.
> > I am actually wondering about the current state of KDE accessibility -
> > whether AT clients under KDE currently depend on gnome/gconf libraries
> > (especially if they use the gconf key
> > '/desktop/gnome/interface/accessibility' to enable AT support) .
> > Thanks,
> > Ashutosh
> >
> >
> > ______________________________________________________________________
> > _______________________________________________
> > kde-accessibility mailing list
> > kde-accessibility at kde.org
> > https://mail.kde.org/mailman/listinfo/kde-accessibility
>
>
Hi Bill,

These details are really useful. Thanks!
I suppose things will get much better on KDE after Qt4 or with more
application specific Orca scripts.

Thanks,
Ashu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-accessibility/attachments/20060626/1a7fc391/attachment-0001.html