[Kde-accessibility] Re: accessibility.kde.org

[Gunnar Schmi Dt]

Hello,

On Thursday 31 October 2002 12:41, Olaf Jan Schmidt wrote:
> [...]
> I can help updating the site. Some weeks ago, you suggested discussing =
an
> "agenda" for KDE Accessibility. As we are only very few people, this
> should basically reflect the work currently done, plus a perspective fo=
r
> things which will hopefully be done sooner or later.
>
> My ideas where
>
> 1. Document existing programs on the web site (KMouth, KMousetool, KMag=
,
> Speaker plug-ins, any other?)
>
> I could do this.
>
I would say that we do not need to duplicate documentation. If there does=
=20
already exist some good documentation we could link to it. However, each=20
existing program should be either documented or represented by a ling to =
the=20
external documentation.

With "some good documentation" I mean not only to list the basic features=
 the=20
programs have but also:
- some sections about "frequently asked questions" (both those in the doc=
book=20
of the programs and others that were later asked by users)
- documentation about APIs, DCOP-messages, file formats etc. (where=20
applicable.)
- tutorials how to set things up
- etc. etc.

> 2. Documentation of the Proklam work being currently done. This should
> include answers to the questions:
> What is Proklam?
> How is cooperation with gnome-speech possible?
> How do I use Proklam in my programs?
> (explaination of dcop function, of the kspeech class, of the possible
> changes to basic KDE parts like KTexteditor, and of the XML language us=
ed
> by Proklam)
>
Proklam will become a part of kdelibs, so it might make sense to document=
=20
proklam in a section about features that are implemented in the core of K=
DE.=20
However, the full documentation (frequently asked questions, API,=20
DCOP-messages, tutorials etc.) might become an own section that is linked=
 in=20
the section about accessibility in the core of KDE.

> As Proklam needs to be coded first, an answer to the general ideas behi=
nd
> Proklam might be enough for the start.
>
I think that the documention about the API of Proklam needs to be written=
 as=20
soon as possible so that others can read it and design their programs to =
use=20
Proklam once Proklam is ready. In that sense I would suggest that the KSp=
eech=20
class of Proklam should soon be implemented as it is that part of Proklam=
=20
that gets linked into the programs that want to use Proklam.

> 3. A concrete stragety paper for implementing an AT-SPI in KDE. Gunnar =
is
> planning to come up with some ideas once KDE 3.2 is out, so we can
> contact kde-core-devel for hints and ideas.
> We will be lacking the time to implement all of this, but IMHO it would=
 be
> great to decide upon a general stragety so that people interested in
> accessibilty issues have the option to start coding small pieces.
>
Well, I will definitely not wait until KDE 3.2 is out, that would be far =
to=20
late ;-). Depending on the time I have besides my studies I want to relea=
se=20
version 0.8 of KMouth by the end of November. After that is done I will t=
ake=20
some time to design possible architectures for accessibility in KDE. If a=
ll=20
goes well I will send the a document describing these architectures in ea=
rly=20
December. After that we can discuss which architecture we would like to b=
e=20
used in KDE. It would be good if some kde-core devellopers could join tha=
t=20
discussion.

> I am also wondering about whether it might be possible to create a
> kdeaccess package for KDE 3.2 or KDE 3.3 - once Proklam is ready and
> programs like KMouth and the Speaker plug-ins are working with Proklam.
> Pupeno wishes Proklam to go into kdelibs, but some of the plug-ins migh=
t
> then go into kdeaccess. I might be also an idea to create kdeaccess-gno=
me
> for interoperability bridges.
>
> [...]
I did already plan to put KMouth into CVS once it has reached version 0.8=
=20
final, so that KMouth would certainly become a part of that new package. =
As=20
for the other accessibility programs (KMousetool, KMag, Speaker plug-ins=20
etc.) we would need to ask their devellopers whether they want their prog=
rams=20
in CVS on kde.org, as putting them into the kdeaccess package would requi=
re=20
that they are in the CVS.

Gunnar Schmi Dt