[Kde-accessibility] Proklam and KMouth

[Pupeno]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 23 September 2002 16:32, Olaf Jan Schmidt wrote:
> If KDE programs (like KMouth) are running within Gnome, then I would love
> to see them using gnome-speech without having to start KDE and
> configuring Proklam first. I would also like to see Gnome programs working
> in KDE using Proklam without gnome-speech being configured.
You won't have to run KDE to configure Proklam as I think you won't have tu=
=20
run gnome to configure gnome-speech.
The problem here is that an application doesn't really know if it's running=
 in=20
KDE or Gnome and it still wouldn't matter... supouse I'm running KDE but I=
=20
use gnome-speech because it supports some TTS that is not yet suported by=20
Proklam, then you may want, although everything is KDE, KMouth to use=20
gnome-speech... but that would add a lot of complexity to the applications=
=20
like KMouth and is not worth it as configuring Proklam or I think=20
gnome-speech outside they're respective DE won't be a big issue.
The other question is that the libraries that KDE and Gnome provide are mea=
nt=20
to allow easy and rapid development of application. Proklam is meant to be=
=20
integrated easyly in any KDE application as I think gnome-speech is meant t=
o=20
be easyly integrated in any Gnome/GTK+ application. That means that other=20
anything diferent than that would be harder and maintain cross dependencies=
=20
for each application would make the projects imposible to mantain.


> This would mean that either both plug-ins would need to be installed by
> default, or the two bridges would need to be a part of Proklam itself.
>
> > Then if gnome-speech use Festival or ViaVoice is up to the configuration
> > of gnome-speech. This idea was suggested by Gunnar if I'm not wrong and
> > I think it's very feasible. What do you think about ?
>
> If there is no configuration possibility in this plug-in, then it might as
> well not be a plug-in but a bridge in proklam itself - apart from the
> dependency issue.
>
> > And as they're plug ins, there's no problem in making a plug in
> > dependant and all the libraries existent out there (if the libraries
> > aren't there, the plug in won't compile/work) but as KSpeech will go
> > directly into kdelibs, it shouldn't depend in anything outside KDE.
>
> KDE does already depend on several other libraries, see
> http://www.kde.org/announcements/announce-3.0.html#source_code-library_re=
qu
>irements
> I think some of them are Gnome libraries, but I am not completely sure.

Yes, I know... some of them come from the Gnome project... what I mean is t=
hat=20
I don't want to add more dependencies to KDE. If it where something vital,=
=20
it's ok, but it's not something vital, such behaviours would lead to chaos.

> Do you know whether the core developers would have objections to using
> these libraries if there are good reasons for using them?
I don't think they'll have any objections... but then we have the problem o=
f=20
the definition of 'good resons' ;)

> Hopefully some day someone will write AT-SPI support for KDE, as it is the
> only easy way to make KDE work with accessibility devices like Braille
> displays. Then glib and libatk need to be imported by KDE anyway. And any
> KDE program wishing to to support Braille devices will have this
> dependency, unless a more complex KDE solution is developed by someone.
>
> Maybe this is not important right now, as I do not know of any such
> project, but our a strategy towards the GAP will have influence upon
> other KDE projects planing to add GAP support to KDE - like support for
> Braille devices. This makes the decision is not easier.
I'm a bit confused here...
Can somebody helping what's being done and what's done and by who, Gnome=20
accesibility page is not really clear.
I try to define this things, please correct me:

AT Accessibility API: This is the api used by non-gnome/gtk applications to=
=20
obtain accesibility features.
GNOME Accessibility API: This is the api used by gnome/gtk applications to=
=20
obtain accesibility features.
Java Accessibility API: The API used by java apps to get accesibility=20
features.

Am I wrong to think that there might be, in te future a KDE Accessibility A=
PI=20
for KDE apps ?

ATK API: The set of modifications to be done to the Gtk+ widgets ?
AT-SPI: A genera library to provide accesibility features (with AT=20
Accessibility API?).
GAP: Gnome Accessibility Project ?


> It could be possible to compile the bridge optionally into Proklam, so KDE
> does not neccessarily depend on it. On the other hand, a plug in can
> easier be installed later on a precompiled system.
>
> Having the bridges as plug-ins has the disadvantage of being an
> optional solution rather than a general solution ensuring interoperability
> in all cases. But I could live with this optional solution for the moment
> - if other programmers implement the AT-SPI later, then Proklam
> could still be changed to a general solution.
I don't understand why a plug in is not a general solution and how a genera=
l=20
solution would be.

=2D --=20
Pupeno: pupeno@pupeno.com
http://www.pupeno.com
=2D ---
Help the hungry children of Argentina,=20
please go to (and make it your homepage):
http://www.porloschicos.com/servlet/PorLosChicos?comando=3Ddonar
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9j69gLr8z5XzmSDQRAlOQAJ9mQI84ixFF0JY7KHlSRFeqLik+CQCgxACk
Qp5ucbkTaqR5UnuH/AtlSiM=3D
=3DfCNT
=2D----END PGP SIGNATURE-----