[Kde-accessibility] Proklam and KMouth

[Olaf Jan Schmidt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Pupeno,

Am Montag, 23. September 2002 20:34:20 schrieb Pupeno:
> All the interoperatibility should go directly into Proklam, I think the
> best way to do it would be to make a plug in and then gnome-speech
> would just another TTS to Proklam, as Festival or FreeTTS are.

If KDE programs (like KMouth) are running within Gnome, then I would love=
=20
to see them using gnome-speech without having to start KDE and=20
configuring Proklam first. I would also like to see Gnome programs workin=
g=20
in KDE using Proklam without gnome-speech being configured.

This would mean that either both plug-ins would need to be installed by=20
default, or the two bridges would need to be a part of Proklam itself.=20

> Then if gnome-speech use Festival or ViaVoice is up to the configuratio=
n
> 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 a=
s=20
well not be a plug-in but a bridge in proklam itself - apart from the=20
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=
quirements

I think some of them are Gnome libraries, but I am not completely sure.

Do you know whether the core developers would have objections to using=20
these libraries if there are good reasons for using them?

Hopefully some day someone will write AT-SPI support for KDE, as it is th=
e=20
only easy way to make KDE work with accessibility devices like Braille=20
displays. Then glib and libatk need to be imported by KDE anyway. And any=
=20
KDE program wishing to to support Braille devices will have this=20
dependency, unless a more complex KDE solution is developed by someone.=20

Maybe this is not important right now, as I do not know of any such=20
project, but our a strategy towards the GAP will have influence upon=20
other KDE projects planing to add GAP support to KDE - like support for=20
Braille devices. This makes the decision is not easier.

It could be possible to compile the bridge optionally into Proklam, so KD=
E=20
does not neccessarily depend on it. On the other hand, a plug in can=20
easier be installed later on a precompiled system.

Having the bridges as plug-ins has the disadvantage of being an=20
optional solution rather than a general solution ensuring interoperabilit=
y=20
in all cases. But I could live with this optional solution for the moment=
=20
- - if other programmers implement the AT-SPI later, then Proklam
could still be changed to a general solution.

Well, I hope I have not confused you with all these thoughts, as I do not=
=20
have a clear opinion myself.

Olaf.
- --=20
Meine Internetseiten:
http://www.GebetGenerator.de, http://www.amen-online.de

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAj2PemgACgkQoLYC8AehV8ftxwCePlzTi7rJ8VWIZzN6Osn1CQ5g
2zgAnjXfsxSB+byefD9yuRg23f4ShmjV
=3DL4pt
-----END PGP SIGNATURE-----