system settings ui

[Jeremy Whiting]

Luke,

First of all thanks for your detailed reply, and sorry it has taken me
3 days to respond... :/

On Sun, May 24, 2015 at 10:33 PM, Luke Yelavich
<luke.yelavich at canonical.com> wrote:
> On Sun, May 24, 2015 at 01:38:04AM AEST, Jeremy Whiting wrote:
>> Hello all,
>>
>> In order to make it easier for those users running a plasma desktop
>> I'd like to create a kde control module to configure
>> speech-dispatcher. For that I have a couple of questions.
>>
>> 1. Should it modify the .conf files directly or use libspeechd with a
>> new api to modify the .conf files? If the former, what method should
>> it used to restart speechd or have it reload it's configuration kill
>> -sighup or some new method in libspeechd to restart the daemon?
>
> The server does reload the configuration when it receives SIGHUP. As for 
> reading configuration files, this is a tricky one. We could role some 
> convenience code together to make it easier for third-party settings apps to 
> work with Speech Dispatcher config files, but in the long run that may not be 
> worth doing.

Yeah, sighup is fine.

>
>> 2. Does it need to be able to modify a system wide configuration with
>> authorization and such or would it be adequate to modify just the
>> user's configuration (is system wide configuration widely used and
>> supported, if so I'll need/want to make the kcm able to read/write the
>> system wide configuration).
>
> Speech Dispatcher can be run either system wide, or per user. The default has 
> been per user for a while, but it can be run system wide. I think we need to 
> do a bit more to make sure Speech dispatcher is a little more confined when 
> run system wide, but that is out of scope for this discussion. As for config, 
> the current model is that the system config files in $sysconfdir are assumed 
> to exist, and read. User config files are checked for in 
> $XDG_CONFIG_HOME/speech-dispatcher, and if found, are used. I think that if 
> the settings UI is running per user, then it should only worry about per-user 
> config files, and if none existed in $XDG_CONFIG_HOME, then they would need 
> to be copied from somewhere into that location and modified appropriately. 
> Unfortunately, there is no easy way to determine whether Speech Dispatcher is 
> running in system mode just by talking to it. This is something that needs 
> addressing.

Well if speech-dispatcher supports both I think I'll need to make both
options available in the kcm also. As for determining which it is,
some api to do that would be handy, but it can also be that the user
knows and chooses which way to configure speechd from the kcm ui
itself. Similar to how spd-conf asks if you want to make a system or
user configuration.

>
>> 3. Are there any plans moving forward to move speech-dispatcher away
>> from .conf files for configuration? For example moving to GSettings or
>> something similar? I don't want to write a kcm that will only be
>> useful for a year before the underlying settings format changes on us
>> or something. Especially since distros are slow to adopt new packages,
>> so it wont get widespread use for at least 6 months or longer.
>
> In the roadmap discussion on list a while back, I raised the possibility of 
> moving to using GSettings. I've even started working on this locally, 
> although I am no further than writing the gsettings XML for the server. Using 
> GSettings would mean we would not need to listen for a unix signal to know 
> when a setting has been changed, however to do so relatively easily requires 
> the use of a Glib main loop, also previously raised in the roadmap discussion 
> on list. This I have also started working on locally, and in fact I have the 
> main thread of the Speech Dispatcher server running using a glib main loop, 
> as well as functionality to shut down the server after a period of time once 
> the last client disconnects.

I haven't dived deep into speech-dispatcher server code, but moving to
using a glib main-loop sounds like a good idea to me. I'd definitely
like to avoid ending up in this category:
http://lists.freedesktop.org/archives/dbus/2015-May/016697.html After
some of our previous discussions on irc I think we've got some aspects
of this we should look into moving away from at some point. I'm
thinking of our string manipulation functions and such, there's
probably a case to be made for using glib's GString and other methods
rather than our own home grown functions.

>
> I think the migration would be 2-fold. We migrate the server to using 
> GSettings first, providing migration code either directly in the server, or 
> as an extra utility, to allow users to migrate their settings accross. At the 
> same time, we could also implement an API to allow clients to change settings 
> in the server. Exactly how this would work is for another discussion I think.

Yeah, that makes sense to me.

>
> Given you are looking at doing this KCM work, I'll prioritize gsettings 
> functionality. I'm not sure what release will include it, as I have a few 
> other things I'd like to include for 0.9, and I think the migration to 
> gsettings is most certainly a 0.9 version bump, given the rather big change.

Please don't change your priorities on my account. The KCM I'm
thinking of creating is a "good to have" feature. Not something urgent
by any means (I can continue to tell users to use sdp-conf until we
are at the point where we can create this ui).

BR,
Jeremy

>
> Luke
>
> _______________________________________________
> Speechd mailing list
> Speechd at lists.freebsoft.org
> http://lists.freebsoft.org/mailman/listinfo/speechd