Re: KSpeech
Torsdag 6. mars 2014 20.34.05 skrev Christoph Feck: > On Thursday 06 March 2014 17:13:19 Jeremy Whiting wrote: > > On Thu, Mar 6, 2014 at 6:43 AM, Frederik Gladhorn > > wrote: > > > Onsdag 5. mars 2014 23.04.12 skrev Jeremy Whiting: > > >> 3. user configurability (As a user I can't set up which voice I > > >> would like all speech-using applications to use) > > > > > > As with other Qt libs, this is more for the platform to set up. > > > Currently qtspeech uses whatever voice is selected system wide > > > (aka the default). I think that is the right approach - follow > > > what we get from the platform. For KDE I'd thus suggest creating > > > a configuration module which lets the user choose the platform > > > defaults. > > > > Yeah, each platform could have its own configuration of the > > defaults sure, the only part missing is a real-time configuration > > change. For example if Jovie is reduced to a kcm to configure > > speech-dispatcher's default voice and I start listening to a pdf > > from okular or something and decide I need the pitch to be lower, > > changing the default voice wont change the voice that > > speech-dispatcher is already using to read the pdf. Maybe that > > could be fixed with a patch to speech-dispatcher to accept > > immediate default changes though, I'll have to think about that. > > Let me refer to http://www.w3.org/TR/2011/WD-css3-speech-20110419/ > which defines attributes a web page can use to influence speech. Would > be nice if we had API supporting web speech. This is interesting in that different synths have already some sort of support for this. > > Regarding voice selection, it would be very useful to allow the > application to specify female/male/child voice via API (in addition to > the ability to let the user reconfigure actual voices). Similar to > letting the application request Sans, Sans Serif, and Monospaced font. > > For example, when generating different voices while reading out e-book > stories. Makes sense. I'd like to get an overview over the native APIs first. Let's collect their capabilities and then try to come up with a sensible compromise. Feel free to gather data here: http://qt-project.org/wiki/QtSpeech Cheers, Frederik > > Christoph Feck (kdepepo) ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KSpeech
On Thursday 06 March 2014 17:13:19 Jeremy Whiting wrote: > On Thu, Mar 6, 2014 at 6:43 AM, Frederik Gladhorn wrote: > > Onsdag 5. mars 2014 23.04.12 skrev Jeremy Whiting: > >> 3. user configurability (As a user I can't set up which voice I > >> would like all speech-using applications to use) > > > > As with other Qt libs, this is more for the platform to set up. > > Currently qtspeech uses whatever voice is selected system wide > > (aka the default). I think that is the right approach - follow > > what we get from the platform. For KDE I'd thus suggest creating > > a configuration module which lets the user choose the platform > > defaults. > > Yeah, each platform could have its own configuration of the > defaults sure, the only part missing is a real-time configuration > change. For example if Jovie is reduced to a kcm to configure > speech-dispatcher's default voice and I start listening to a pdf > from okular or something and decide I need the pitch to be lower, > changing the default voice wont change the voice that > speech-dispatcher is already using to read the pdf. Maybe that > could be fixed with a patch to speech-dispatcher to accept > immediate default changes though, I'll have to think about that. Let me refer to http://www.w3.org/TR/2011/WD-css3-speech-20110419/ which defines attributes a web page can use to influence speech. Would be nice if we had API supporting web speech. Regarding voice selection, it would be very useful to allow the application to specify female/male/child voice via API (in addition to the ability to let the user reconfigure actual voices). Similar to letting the application request Sans, Sans Serif, and Monospaced font. For example, when generating different voices while reading out e-book stories. Christoph Feck (kdepepo) ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KSpeech
On Thu, Mar 6, 2014 at 6:43 AM, Frederik Gladhorn wrote:
> Onsdag 5. mars 2014 23.04.12 skrev Jeremy Whiting:
>> Took a quick read through that just now and it looks pretty promising
>> from what I saw. I guess I don't know my way around gerrit very well
>> because I couldn't see a place to comment on the code like
>> reviewboard.
>> Really the only difference between jovie and that class are the following:
>> 1. jovie has some old code and ui to control jobs at a fine grain that
>> spd doesn't expose really well, so I left it out when I ported ktts to
>> spd.
>
> I would like to expose "voices" and "languages" in a sensible fashion. This is
> tricky to get right cross-platform. I started with something on Linux but
> decided to implement other backends first before attempting to implement voice
> selection.
> For language/locale I think qtspeech should default to the system locale and
> let the user select a different one.
Using the system locale as default makes sense. What do you mean by
"voices" you mean something like spd's voice type (male1, male2,
female1, etc.)
Ktts had a complex system of specifying a voice with xml with
language, voice type, speed, pitch, etc. attributes and if an
attribute was empty it meant any voice with the other attributes was
acceptable. I think that's a bit too fine-grained for most cases
though, most uses I can think of just want to choose the voice type,
or even just the gender, and let the user/defaults choose the rest.
If more complex specification is wanted applications could always use
ssml to change the voice as part of the text they send to qtspeech.
>
>> 2. user defined filters with some sane/useful defaults (if we were to
>> use QtSpeech for kde notifications, set konvi to speak all messages,
>> there's not a way to let the user say change " fregl: you
>> rock" into "jpwhiting says fregl you rock")
>
> Maybe. I'd rather keep qtspeech very simple. My goals where to make it a tiny
> library that is lean, fast and async by using signals and slots.
> I want it to be good enough to be used in apps that use voice navigation, but
> also when writing a screen reader. Some level of configuration is required in
> any case. Let's come up with a good api that makes sense across platforms,
> then I'm in.
Right, simple is definitely good. I'm just wondering if it could
accept plugins that implement some filtering method to filter the
text. Then filters could be as simple as a regex to convert
xml/html/etc. text into something that makes sense audibly like that
example from irc, or a complex filter plugin to change the voice could
inject ssml into the text. Maybe something like
QAbstractSpeechFilter {
public:
virtual QString filterText(QString &text)
};
Then a simple filtermanager (or even part of the existing class) loads
the plugins and when say() is called it passes the text through all
the plugins filterText() methods.
Is there some other Qt library or class that takes plugins for
specific functionality we could use as inspiration for making this
work and look clean also?
>
>> 3. user configurability (As a user I can't set up which voice I would
>> like all speech-using applications to use)
>
> As with other Qt libs, this is more for the platform to set up. Currently
> qtspeech uses whatever voice is selected system wide (aka the default). I
> think that is the right approach - follow what we get from the platform.
> For KDE I'd thus suggest creating a configuration module which lets the user
> choose the platform defaults.
Yeah, each platform could have its own configuration of the defaults
sure, the only part missing is a real-time configuration change. For
example if Jovie is reduced to a kcm to configure speech-dispatcher's
default voice and I start listening to a pdf from okular or something
and decide I need the pitch to be lower, changing the default voice
wont change the voice that speech-dispatcher is already using to read
the pdf. Maybe that could be fixed with a patch to speech-dispatcher
to accept immediate default changes though, I'll have to think about
that.
>
>> 4. dbus, though this isn't as important if each application that uses
>> speech links to the library and speech-dispatcher or the system apis
>> do the async for us already anyway as you said.
> I don't see a point in adding dbus into the mix indeed. One thing that is
> interesting though is what kind of effect you get when opening the speech
> backend from two apps at the same time.
>
>> Items 1 and 4 will be irrelevant in a KF5 world but I'm wondering how
>> 2 and 3 could be added either to qtspeech itself or as a kspeech
>> library that wraps
Re: KSpeech
Onsdag 5. mars 2014 23.04.12 skrev Jeremy Whiting: > Took a quick read through that just now and it looks pretty promising > from what I saw. I guess I don't know my way around gerrit very well > because I couldn't see a place to comment on the code like > reviewboard. > Really the only difference between jovie and that class are the following: > 1. jovie has some old code and ui to control jobs at a fine grain that > spd doesn't expose really well, so I left it out when I ported ktts to > spd. I would like to expose "voices" and "languages" in a sensible fashion. This is tricky to get right cross-platform. I started with something on Linux but decided to implement other backends first before attempting to implement voice selection. For language/locale I think qtspeech should default to the system locale and let the user select a different one. > 2. user defined filters with some sane/useful defaults (if we were to > use QtSpeech for kde notifications, set konvi to speak all messages, > there's not a way to let the user say change " fregl: you > rock" into "jpwhiting says fregl you rock") Maybe. I'd rather keep qtspeech very simple. My goals where to make it a tiny library that is lean, fast and async by using signals and slots. I want it to be good enough to be used in apps that use voice navigation, but also when writing a screen reader. Some level of configuration is required in any case. Let's come up with a good api that makes sense across platforms, then I'm in. > 3. user configurability (As a user I can't set up which voice I would > like all speech-using applications to use) As with other Qt libs, this is more for the platform to set up. Currently qtspeech uses whatever voice is selected system wide (aka the default). I think that is the right approach - follow what we get from the platform. For KDE I'd thus suggest creating a configuration module which lets the user choose the platform defaults. > 4. dbus, though this isn't as important if each application that uses > speech links to the library and speech-dispatcher or the system apis > do the async for us already anyway as you said. I don't see a point in adding dbus into the mix indeed. One thing that is interesting though is what kind of effect you get when opening the speech backend from two apps at the same time. > Items 1 and 4 will be irrelevant in a KF5 world but I'm wondering how > 2 and 3 could be added either to qtspeech itself or as a kspeech > library that wraps qtspeech for kde applications to use. > > Any thoughts on that? I would be pretty interested in helping with > qtspeech if it greatly simplifies or even deprecates jovie as it looks > like it could do possibly. I'd be more than happy to get contributions of course. I cannot promise much from my side, of course I'd like to continue working on this project as time permits (so far it really is a spare time thing). Greetings, Frederik > Jeremy > > On Wed, Mar 5, 2014 at 12:29 PM, Frederik Gladhorn wrote: > > On Tuesday 4. March 2014 16.43.10 Jeremy Whiting wrote: > >> Hello all, I've realized a bit ago that kspeech was not included in > >> > >> the kdelibs split (probably because it was in staging at the time and > >> > >> didn't conform to the other framework policies yet). I've cleaned it > >> > >> up a bit and put it in my scratch space, but have some architectural > >> > >> questions about it before I make it a proper framework. > >> > >> > >> > >> 1. The KSpeech dbus interface is old and showing its age. Many of the > >> > >> methods are no longer implemented in the application itself since it > >> > >> was ported to speech-dispatcher. One thing I would definitely like to > >> > >> do is clean up/remove methods that aren't implemented currently (and > >> > >> possibly re add some later on if speech-dispatcher gets better/more > >> > >> support for job control, etc.) So the question about this is is KF5 > >> > >> time a good time to drop/clean up the dbus interface? > >> > >> > >> > >> 2. The KSpeech interface that was in kdelibs/interfaces is just that a > >> > >> dbus interface only. I would like to make it a proper > >> > >> library/framework with a QObject based class for talking to Jovie (the > >> > >> application that implements the KSpeech dbus interface) and wonder if > >> > >> other things such as what's currently in jovie/libkttsd should be in > >> > >>
Re: KSpeech
Took a quick read through that just now and it looks pretty promising from what I saw. I guess I don't know my way around gerrit very well because I couldn't see a place to comment on the code like reviewboard. Really the only difference between jovie and that class are the following: 1. jovie has some old code and ui to control jobs at a fine grain that spd doesn't expose really well, so I left it out when I ported ktts to spd. 2. user defined filters with some sane/useful defaults (if we were to use QtSpeech for kde notifications, set konvi to speak all messages, there's not a way to let the user say change " fregl: you rock" into "jpwhiting says fregl you rock") 3. user configurability (As a user I can't set up which voice I would like all speech-using applications to use) 4. dbus, though this isn't as important if each application that uses speech links to the library and speech-dispatcher or the system apis do the async for us already anyway as you said. Items 1 and 4 will be irrelevant in a KF5 world but I'm wondering how 2 and 3 could be added either to qtspeech itself or as a kspeech library that wraps qtspeech for kde applications to use. Any thoughts on that? I would be pretty interested in helping with qtspeech if it greatly simplifies or even deprecates jovie as it looks like it could do possibly. Jeremy On Wed, Mar 5, 2014 at 12:29 PM, Frederik Gladhorn wrote: > On Tuesday 4. March 2014 16.43.10 Jeremy Whiting wrote: > >> Hello all, I've realized a bit ago that kspeech was not included in > >> the kdelibs split (probably because it was in staging at the time and > >> didn't conform to the other framework policies yet). I've cleaned it > >> up a bit and put it in my scratch space, but have some architectural > >> questions about it before I make it a proper framework. > >> > >> 1. The KSpeech dbus interface is old and showing its age. Many of the > >> methods are no longer implemented in the application itself since it > >> was ported to speech-dispatcher. One thing I would definitely like to > >> do is clean up/remove methods that aren't implemented currently (and > >> possibly re add some later on if speech-dispatcher gets better/more > >> support for job control, etc.) So the question about this is is KF5 > >> time a good time to drop/clean up the dbus interface? > >> > >> 2. The KSpeech interface that was in kdelibs/interfaces is just that a > >> dbus interface only. I would like to make it a proper > >> library/framework with a QObject based class for talking to Jovie (the > >> application that implements the KSpeech dbus interface) and wonder if > >> other things such as what's currently in jovie/libkttsd should be in > >> the kspeech library also. If I move code from jovie into libkspeech > >> (or merge kspeech interface into libkttsd and make libkttsd a > >> framework likely renamed to libkspeech since libkttsd isn't a public > >> library anyway and has the old ktts name) what's the best way to > >> preserve the history of both the kspeech interface and libkttsd > >> sources. Didn't the plasma or kde-workspaces split do something fancy > >> with git where old history pointed to the old git repo somehow? > >> Along with this, if libkspeech is defining the kspeech dbus interface > >> and has a class to talk to that interface, does the interface still > >> need to be in servicetypes like the dbustexttospeech.desktop file that > >> was installed in /usr/share/kde4/servicetypes in kde4 times? > > > > In case you are interested, I started a cross platform library for tts here: > > https://codereview.qt-project.org/#admin,project,qt/qtspeech,info > > It's a regular Qt module providing a library that currently consists of one > class. > > > > It is currently quite incomplete because it lacks voice/language > configuration. > > On the up side, I implemented basic backends for win/mac/android/linux. > > Linux is using speech-dispatcher, but I was quite dissatisfied with spd's > API. For example it lacks proper free functions for the structs it allocates > - so one has to basically leak them. > > I didn't dare looking at Jovie/kttsd since I used the Qt license. > > > > Greetings, > > Frederik > > > >> > >> thanks, > >> Jeremy > >> ___ > >> Kde-frameworks-devel mailing list > >> Kde-frameworks-devel@kde.org > >> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel > > > > > ___ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KSpeech
On Tuesday 4. March 2014 16.43.10 Jeremy Whiting wrote: > Hello all, I've realized a bit ago that kspeech was not included in > the kdelibs split (probably because it was in staging at the time and > didn't conform to the other framework policies yet). I've cleaned it > up a bit and put it in my scratch space, but have some architectural > questions about it before I make it a proper framework. > > 1. The KSpeech dbus interface is old and showing its age. Many of the > methods are no longer implemented in the application itself since it > was ported to speech-dispatcher. One thing I would definitely like to > do is clean up/remove methods that aren't implemented currently (and > possibly re add some later on if speech-dispatcher gets better/more > support for job control, etc.) So the question about this is is KF5 > time a good time to drop/clean up the dbus interface? > > 2. The KSpeech interface that was in kdelibs/interfaces is just that a > dbus interface only. I would like to make it a proper > library/framework with a QObject based class for talking to Jovie (the > application that implements the KSpeech dbus interface) and wonder if > other things such as what's currently in jovie/libkttsd should be in > the kspeech library also. If I move code from jovie into libkspeech > (or merge kspeech interface into libkttsd and make libkttsd a > framework likely renamed to libkspeech since libkttsd isn't a public > library anyway and has the old ktts name) what's the best way to > preserve the history of both the kspeech interface and libkttsd > sources. Didn't the plasma or kde-workspaces split do something fancy > with git where old history pointed to the old git repo somehow? > Along with this, if libkspeech is defining the kspeech dbus interface > and has a class to talk to that interface, does the interface still > need to be in servicetypes like the dbustexttospeech.desktop file that > was installed in /usr/share/kde4/servicetypes in kde4 times? In case you are interested, I started a cross platform library for tts here: https://codereview.qt-project.org/#admin,project,qt/qtspeech,info It's a regular Qt module providing a library that currently consists of one class. It is currently quite incomplete because it lacks voice/language configuration. On the up side, I implemented basic backends for win/mac/android/linux. Linux is using speech-dispatcher, but I was quite dissatisfied with spd's API. For example it lacks proper free functions for the structs it allocates - so one has to basically leak them. I didn't dare looking at Jovie/kttsd since I used the Qt license. Greetings, Frederik > > thanks, > Jeremy > ___ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KSpeech
Hello, On Tuesday 04 March 2014 16:43:10 Jeremy Whiting wrote: > I've realized a bit ago that kspeech was not included in > the kdelibs split (probably because it was in staging at the time and > didn't conform to the other framework policies yet). I've cleaned it > up a bit and put it in my scratch space, but have some architectural > questions about it before I make it a proper framework. > > 1. The KSpeech dbus interface is old and showing its age. [...] > > 2. The KSpeech interface that was in kdelibs/interfaces is just that a > dbus interface only. [...] I think that's mainly why it wasn't moved over so far... if you do all that it's pretty much an almost completely new thing. So from my perspective feel free to clean it up, turn it in a proper framework etc. That said, because of the work it probably means targeting KF 5.1 to include it in the list again. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
KSpeech
Hello all, I've realized a bit ago that kspeech was not included in the kdelibs split (probably because it was in staging at the time and didn't conform to the other framework policies yet). I've cleaned it up a bit and put it in my scratch space, but have some architectural questions about it before I make it a proper framework. 1. The KSpeech dbus interface is old and showing its age. Many of the methods are no longer implemented in the application itself since it was ported to speech-dispatcher. One thing I would definitely like to do is clean up/remove methods that aren't implemented currently (and possibly re add some later on if speech-dispatcher gets better/more support for job control, etc.) So the question about this is is KF5 time a good time to drop/clean up the dbus interface? 2. The KSpeech interface that was in kdelibs/interfaces is just that a dbus interface only. I would like to make it a proper library/framework with a QObject based class for talking to Jovie (the application that implements the KSpeech dbus interface) and wonder if other things such as what's currently in jovie/libkttsd should be in the kspeech library also. If I move code from jovie into libkspeech (or merge kspeech interface into libkttsd and make libkttsd a framework likely renamed to libkspeech since libkttsd isn't a public library anyway and has the old ktts name) what's the best way to preserve the history of both the kspeech interface and libkttsd sources. Didn't the plasma or kde-workspaces split do something fancy with git where old history pointed to the old git repo somehow? Along with this, if libkspeech is defining the kspeech dbus interface and has a class to talk to that interface, does the interface still need to be in servicetypes like the dbustexttospeech.desktop file that was installed in /usr/share/kde4/servicetypes in kde4 times? thanks, Jeremy ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113844: Move kspeech interface to tier3
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113844/#review43622 --- This review has been submitted with commit c18ffcc197a6106f2f1136cac4bcd32a63b6ca17 by Jeremy Whiting to branch frameworks. - Commit Hook On Nov. 13, 2013, 6:01 p.m., Jeremy Whiting wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/113844/ > --- > > (Updated Nov. 13, 2013, 6:01 p.m.) > > > Review request for KDE Frameworks. > > > Repository: kdelibs > > > Description > --- > > It builds and installs. Will make it conform to framework structure with src/ > and whatnot after this is shipped. > > > Diffs > - > > interfaces/CMakeLists.txt 9fa4e1b23e4671dae25518c9d8d3fe1369f9b1a6 > interfaces/kspeech/CMakeLists.txt > interfaces/kspeech/Mainpage.dox > interfaces/kspeech/dbustexttospeech.desktop > interfaces/kspeech/kspeech.h > interfaces/kspeech/org.kde.KSpeech.xml > staging/CMakeLists.txt c77fa19ad700c6e9af68434d7c6fdc304fceeba6 > > Diff: http://git.reviewboard.kde.org/r/113844/diff/ > > > Testing > --- > > > Thanks, > > Jeremy Whiting > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113844: Move kspeech interface to tier3
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113844/ --- (Updated Nov. 13, 2013, 6:57 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kdelibs Description --- It builds and installs. Will make it conform to framework structure with src/ and whatnot after this is shipped. Diffs - interfaces/CMakeLists.txt 9fa4e1b23e4671dae25518c9d8d3fe1369f9b1a6 interfaces/kspeech/CMakeLists.txt interfaces/kspeech/Mainpage.dox interfaces/kspeech/dbustexttospeech.desktop interfaces/kspeech/kspeech.h interfaces/kspeech/org.kde.KSpeech.xml staging/CMakeLists.txt c77fa19ad700c6e9af68434d7c6fdc304fceeba6 Diff: http://git.reviewboard.kde.org/r/113844/diff/ Testing --- Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113844: Move kspeech interface to tier3
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113844/#review43621 --- Ship it! Ship It! - Aleix Pol Gonzalez On Nov. 13, 2013, 6:01 p.m., Jeremy Whiting wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/113844/ > --- > > (Updated Nov. 13, 2013, 6:01 p.m.) > > > Review request for KDE Frameworks. > > > Repository: kdelibs > > > Description > --- > > It builds and installs. Will make it conform to framework structure with src/ > and whatnot after this is shipped. > > > Diffs > - > > interfaces/CMakeLists.txt 9fa4e1b23e4671dae25518c9d8d3fe1369f9b1a6 > interfaces/kspeech/CMakeLists.txt > interfaces/kspeech/Mainpage.dox > interfaces/kspeech/dbustexttospeech.desktop > interfaces/kspeech/kspeech.h > interfaces/kspeech/org.kde.KSpeech.xml > staging/CMakeLists.txt c77fa19ad700c6e9af68434d7c6fdc304fceeba6 > > Diff: http://git.reviewboard.kde.org/r/113844/diff/ > > > Testing > --- > > > Thanks, > > Jeremy Whiting > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113844: Move kspeech interface to tier3
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113844/ --- (Updated Nov. 13, 2013, 11:01 a.m.) Review request for KDE Frameworks. Changes --- Updated to move to staging since the final tier isn't decided yet. Repository: kdelibs Description --- It builds and installs. Will make it conform to framework structure with src/ and whatnot after this is shipped. Diffs (updated) - interfaces/CMakeLists.txt 9fa4e1b23e4671dae25518c9d8d3fe1369f9b1a6 interfaces/kspeech/CMakeLists.txt interfaces/kspeech/Mainpage.dox interfaces/kspeech/dbustexttospeech.desktop interfaces/kspeech/kspeech.h interfaces/kspeech/org.kde.KSpeech.xml staging/CMakeLists.txt c77fa19ad700c6e9af68434d7c6fdc304fceeba6 Diff: http://git.reviewboard.kde.org/r/113844/diff/ Testing --- Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113844: Move kspeech interface to tier3
> On Nov. 13, 2013, 10:22 a.m., Aleix Pol Gonzalez wrote: > > Why is it tier3? It doesn't seem to depend on anything, no? No it doesn't depend on anything, but is specific to kde platform. I put it into tier3 because that's what I was told in the meeting, maybe another tier makes more sense though. - Jeremy --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113844/#review43616 --- On Nov. 13, 2013, 10:16 a.m., Jeremy Whiting wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/113844/ > --- > > (Updated Nov. 13, 2013, 10:16 a.m.) > > > Review request for KDE Frameworks. > > > Repository: kdelibs > > > Description > --- > > It builds and installs. Will make it conform to framework structure with src/ > and whatnot after this is shipped. > > > Diffs > - > > interfaces/CMakeLists.txt 9fa4e1b23e4671dae25518c9d8d3fe1369f9b1a6 > interfaces/kspeech/CMakeLists.txt > interfaces/kspeech/Mainpage.dox > interfaces/kspeech/dbustexttospeech.desktop > interfaces/kspeech/kspeech.h > interfaces/kspeech/org.kde.KSpeech.xml > tier3/CMakeLists.txt c801fd299d95f64d28676f80e86e2c86f9b39024 > > Diff: http://git.reviewboard.kde.org/r/113844/diff/ > > > Testing > --- > > > Thanks, > > Jeremy Whiting > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113844: Move kspeech interface to tier3
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113844/#review43616 --- Why is it tier3? It doesn't seem to depend on anything, no? - Aleix Pol Gonzalez On Nov. 13, 2013, 5:16 p.m., Jeremy Whiting wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/113844/ > --- > > (Updated Nov. 13, 2013, 5:16 p.m.) > > > Review request for KDE Frameworks. > > > Repository: kdelibs > > > Description > --- > > It builds and installs. Will make it conform to framework structure with src/ > and whatnot after this is shipped. > > > Diffs > - > > interfaces/CMakeLists.txt 9fa4e1b23e4671dae25518c9d8d3fe1369f9b1a6 > interfaces/kspeech/CMakeLists.txt > interfaces/kspeech/Mainpage.dox > interfaces/kspeech/dbustexttospeech.desktop > interfaces/kspeech/kspeech.h > interfaces/kspeech/org.kde.KSpeech.xml > tier3/CMakeLists.txt c801fd299d95f64d28676f80e86e2c86f9b39024 > > Diff: http://git.reviewboard.kde.org/r/113844/diff/ > > > Testing > --- > > > Thanks, > > Jeremy Whiting > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 113844: Move kspeech interface to tier3
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113844/ --- Review request for KDE Frameworks. Repository: kdelibs Description --- It builds and installs. Will make it conform to framework structure with src/ and whatnot after this is shipped. Diffs - interfaces/CMakeLists.txt 9fa4e1b23e4671dae25518c9d8d3fe1369f9b1a6 interfaces/kspeech/CMakeLists.txt interfaces/kspeech/Mainpage.dox interfaces/kspeech/dbustexttospeech.desktop interfaces/kspeech/kspeech.h interfaces/kspeech/org.kde.KSpeech.xml tier3/CMakeLists.txt c801fd299d95f64d28676f80e86e2c86f9b39024 Diff: http://git.reviewboard.kde.org/r/113844/diff/ Testing --- Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: the kspeech interface
On Saturday 09 November 2013 11:47:16 David Faure wrote: > On Friday 08 November 2013 22:45:33 Jeremy Whiting wrote: > > Could we move the dbus interface into > > kdeaccessibility/jovie and install it only when jovie is installed, > > This would create a compile-time dependency on kdeaccessibility, > in all the apps that use that dbus interface. > > I think this circles back to kdbusaddons, but I'll give time to e.g. Kévin > to give his input. Not the scope of KDBusAddons IMO. I'd say it's about integrating with our workspace services, so I'd lean more toward a tier 4 framework. We don't have a place for this kind of things yet... We could open a section in framework integration for that. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: the kspeech interface
On Friday 08 November 2013 22:45:33 Jeremy Whiting wrote: > Oops, that link was just users of soPlainText. It seems > http://lxr.kde.org/ident?i=KSpeech the class itself is used in quite a > few places, and is how any application uses speech capabilities. I > guess kdbusaddons is as good a place as any for it and it will need to > stay in kdelibs itself. Wait, there is no class defined in interfaces/kspeech/kspeech.h, only a few enums. The DBUS xml file in that dir is the one that the application use in order to generate a org::kde::KSpeech class. So there's no *library* code in kdelibs for this currently, but there's still two files that need to be installed by a framework, for apps to compile. > Could we move the dbus interface into > kdeaccessibility/jovie and install it only when jovie is installed, This would create a compile-time dependency on kdeaccessibility, in all the apps that use that dbus interface. I think this circles back to kdbusaddons, but I'll give time to e.g. Kévin to give his input. Thanks! -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: the kspeech interface
Oops, that link was just users of soPlainText. It seems http://lxr.kde.org/ident?i=KSpeech the class itself is used in quite a few places, and is how any application uses speech capabilities. I guess kdbusaddons is as good a place as any for it and it will need to stay in kdelibs itself. On Fri, Nov 8, 2013 at 10:40 PM, Jeremy Whiting wrote: > I was actually wondering that myself the other day as I added to it in > kdelibs master (that got branched into KDE/4.12) for a feature that > hit jovie in KDE SC 4.12. > > It's used but really only needed to expose jovie's dbus interface for > applications to use. Interestingly, knotify uses jovie but doesn't > include kspeech.h somehow. Could we move the dbus interface into > kdeaccessibility/jovie and install it only when jovie is installed, > and use the dbus interface the same way it is used in knotify in the > places it's currently used directly? > > Jeremy > > On Fri, Nov 8, 2013 at 5:53 PM, David Faure wrote: >> Hi Jeremy, >> >> I'm looking at kdelibs-frameworks/interface/kspeech, and trying to find a >> home >> for it, in the KF5 reorganization. >> >> I see that it's actually used in a number of places >> (http://lxr.kde.org/ident?i=soPlainText for instance). >> and that it's basically just a header file that depends only on QtCore, >> plus some data files (dbus xml, desktop file). >> >> Are you still happy with that interface? >> Any idea where it would belong, in KF5? >> Maybe in kdbusaddons, since it's only usable with a dbus dependency? >> >> -- >> David Faure, fa...@kde.org, http://www.davidfaure.fr >> Working on KDE, in particular KDE Frameworks 5 >> ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: the kspeech interface
I was actually wondering that myself the other day as I added to it in kdelibs master (that got branched into KDE/4.12) for a feature that hit jovie in KDE SC 4.12. It's used but really only needed to expose jovie's dbus interface for applications to use. Interestingly, knotify uses jovie but doesn't include kspeech.h somehow. Could we move the dbus interface into kdeaccessibility/jovie and install it only when jovie is installed, and use the dbus interface the same way it is used in knotify in the places it's currently used directly? Jeremy On Fri, Nov 8, 2013 at 5:53 PM, David Faure wrote: > Hi Jeremy, > > I'm looking at kdelibs-frameworks/interface/kspeech, and trying to find a home > for it, in the KF5 reorganization. > > I see that it's actually used in a number of places > (http://lxr.kde.org/ident?i=soPlainText for instance). > and that it's basically just a header file that depends only on QtCore, > plus some data files (dbus xml, desktop file). > > Are you still happy with that interface? > Any idea where it would belong, in KF5? > Maybe in kdbusaddons, since it's only usable with a dbus dependency? > > -- > David Faure, fa...@kde.org, http://www.davidfaure.fr > Working on KDE, in particular KDE Frameworks 5 > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
the kspeech interface
Hi Jeremy, I'm looking at kdelibs-frameworks/interface/kspeech, and trying to find a home for it, in the KF5 reorganization. I see that it's actually used in a number of places (http://lxr.kde.org/ident?i=soPlainText for instance). and that it's basically just a header file that depends only on QtCore, plus some data files (dbus xml, desktop file). Are you still happy with that interface? Any idea where it would belong, in KF5? Maybe in kdbusaddons, since it's only usable with a dbus dependency? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
