system settings ui

[Luke Yelavich]

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.

> 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.

> 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 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.

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.

Luke