[Accessibility] qtspeech status

[Jeremy Whiting]

Luke,

Yeah, that's fine to remove spd-conf completely and use gsettings for
settings, np. I was thinking the kcm would write to the .ini files
themselves, but once speech-dispatcher is using gsettings I guess the
kcm would need to link to glib and use the GSettings api to read/write
configuration changes. I don't think that will be a problem though.
And for power users they can use spd-conf itself currently, or use
gsettings command-line arguments to change settings as needed (or if
gnome comes up with a ui to tweak the gsettings, that works too I
guess, maybe inside orca or whatnot, dunno).

BR,
Jeremy


On Mon, Oct 13, 2014 at 8:21 PM, Luke Yelavich
<luke.yelavich at canonical.com> wrote:
> On Tue, Oct 14, 2014 at 06:56:46AM AEDT, Jeremy Whiting wrote:
>> Also, I had imagined that rather than having spd default configuration
>> api in qtspeech itself that we could/would have jovie become a kcm to
>> wrap spd-conf itself. Maybe another tool could be added like qtconfig
>> too, not sure, for those not wanting for whatever reason to run a kcm
>> or spd-conf itself.
>
> At the moment a roadmap of future Speech Dispatcher development discussion is happening on the Speech Dispatcher list. One thing that Brailcom initially proposed, and I support, is moving Speech Dispatcher's configuration to gsettings. I would like to take this further, and allow clients to be able to configure settings themselves on a client basis, and it would be implemented such that the client would not know how the settings were being handled. So given this is implemented, I woudl see no reason for any of your code to wrap spd-conf, since spd-conf would likely be refactored to allw the user to configure Speech Dispatcher settings.
>
> Luke
> _______________________________________________
> Accessibility mailing list
> Accessibility at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/accessibility