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

List:       kde-devel
Subject:    Re: [Kde-accessibility] kded, autoload ? load on demand ?
From:       Bill Haneman <bill.haneman () sun ! com>
Date:       2003-02-28 16:24:17
[Download RAW message or body]

On Fri, 2003-02-28 at 16:02, Pupeno wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Friday 28 February 2003 10:19, Bill Haneman wrote:
> > On Fri, 2003-02-28 at 14:43, Pupeno wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > I'm refactoring Proklam to KTTSD and one of the big changes is that it
> > > won't be a stand alone application any longger but a kded module, but I
> > > don't know about how to load it...
> >
> > One thing which I would request is that KTTSD remain executable/loadable
> > via some sort of wrapper, so that KTTSD could be used as a back-end for
> > GNOME-speech on an integrated desktop.
> In the case of a gnome desktop, gnome-speech will be the backend for kttsd, in 
> the case of a kde desktop, kttsd will be the back end for gnome-speech, right 
> ?

What I mean was that on a gnome desktop, it is possible that kttsd might
be used as one of the backends to gnome-speech.

This topic can get confusing because it depends on what scenario you are
talking about, and whether you are talking about "gnome app running on a
kde desktop" or a "kde application running on a gnome desktop".  There
is also the case for "kde application that wants to use a TTS engine for
which no KTTSD driver exists".

> In the case of a kde desktop, kded will be running so, gnome-speech using 
> kttsd as a back end is no problem (if kded is running, kttsd can be loaded, 
> automatically as Lubos Lunak explained (kde-devel only)).

By "back-end" in this sense I would expect that on a kde desktop, kde
applications would look for kttsd via kded as you explain; the kttsd
service might use gnome-speech as a back-end to do the actual speaking.

> In the case of a gnome desktop, kttsd (using gnome-desktop as backend) will be 
> needed when a kde application is run, and if an application needs kttsd it 
> also needs kded and kded will be run on demand by that application.
> So, no wrapper is needed.

I think we are talking about slightly different cases - but the scenario
you describe above also makes sense.  

> If I'm wrong, please, correct me.

In fact you want to be able to support all of the following stacks:

KDE-app : kttsd : gnome-speech : gnome-speech-driver : TTS engine
KDE-app : kttsd : kttsd-driver : TTS engine
gnome-app : gnome-speech : kttsd-backend : kttsd-driver : TTS engine
gnome-app : gnome-speech : gnome-speech-driver : TTS engine

The second and fourth stacks are the 
"apps using their 'native' TTS framework", and the first and third
stacks are 
"apps using their 'native TTS API' to speak to alternative back-end".

IN both cases it actually doesn't matter so much whether GNOME or
the KDE desktop is running, in order to bridge between application types
in these cases, *both* TTS frameworks must be loaded and active.

That's one reason why I was hoping we would not have kttsd *and*
gnome-speech as separate things, since in order to interoperate, both
frameworks will have to be loaded and active.

regards,

Bill





> This would be the case where the interoperatibility with gnome-speech and 
> kttsd is done by plug ins... is there anything better to do ?
> Thank you.
> - -- 
> Pupeno: pupeno@kde.org
> KDE Accessibility co-maintainer
> http://accessibility.kde.org
> - ---
> Help the hungry children of Argentina,
> please go to (and make it your homepage):
> http://www.porloschicos.com/servlet/PorLosChicos?comando=donar
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (GNU/Linux)
> 
> iD8DBQE+X4gfLr8z5XzmSDQRAjUFAKDcxw0u51NGwZnnOzM9tvNaJx8VEgCgxHlg
> f1a7HCbQ9v+/2EvV1X26SOo=
> =u3Zi
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> kde-accessibility mailing list
> kde-accessibility@mail.kde.org
> http://mail.kde.org/mailman/listinfo/kde-accessibility
-- 
Bill Haneman <bill.haneman@sun.com>

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]