[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-accessibility
Subject:    Re: [Kde-accessibility] Re: accessibility.kde.org
From:       Gunnar Schmi Dt <gunnar () schmi-dt ! de>
Date:       2002-11-01 16:12:35
[Download RAW message or body]

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 for
> 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 
already exist some good documentation we could link to it. However, each 
existing program should be either documented or represented by a ling to the 
external documentation.

With "some good documentation" I mean not only to list the basic features the 
programs have but also:
- some sections about "frequently asked questions" (both those in the docbook 
of the programs and others that were later asked by users)
- documentation about APIs, DCOP-messages, file formats etc. (where 
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 used
> by Proklam)
>
Proklam will become a part of kdelibs, so it might make sense to document 
proklam in a section about features that are implemented in the core of KDE. 
However, the full documentation (frequently asked questions, API, 
DCOP-messages, tutorials etc.) might become an own section that is linked in 
the section about accessibility in the core of KDE.

> As Proklam needs to be coded first, an answer to the general ideas behind
> Proklam might be enough for the start.
>
I think that the documention about the API of Proklam needs to be written as 
soon as possible so that others can read it and design their programs to use 
Proklam once Proklam is ready. In that sense I would suggest that the KSpeech 
class of Proklam should soon be implemented as it is that part of Proklam 
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 
late ;-). Depending on the time I have besides my studies I want to release 
version 0.8 of KMouth by the end of November. After that is done I will take 
some time to design possible architectures for accessibility in KDE. If all 
goes well I will send the a document describing these architectures in early 
December. After that we can discuss which architecture we would like to be 
used in KDE. It would be good if some kde-core devellopers could join that 
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 might
> then go into kdeaccess. I might be also an idea to create kdeaccess-gnome
> for interoperability bridges.
>
> [...]
I did already plan to put KMouth into CVS once it has reached version 0.8 
final, so that KMouth would certainly become a part of that new package. As 
for the other accessibility programs (KMousetool, KMag, Speaker plug-ins 
etc.) we would need to ask their devellopers whether they want their programs 
in CVS on kde.org, as putting them into the kdeaccess package would require 
that they are in the CVS.

Gunnar Schmi Dt
_______________________________________________
kde-accessibility mailing list
kde-accessibility@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-accessibility
[prev in list] [next in list] [prev in thread] [next in thread]