I’m the author of Pied, a tool for easily installing and configuring high quality text-to-speech voices, for use with speech-dispatcher. A walk through of the application’s main functionality can be viewed in this video: https://www.youtube.com/watch?v=o3Izy3E3IRU (The Orca screen reader is running throughout, showing the voices in action.)
I would like to request permission to use the personal-files interface, this is needed to write to $HOME/.config/speech-dispatcher to configure speech-dispatcher for the user. Pied also accesses $HOME/.config/speech-dispatcher.orig for saving existing speech-dispatcher configuration files before modifying them. I’ve named the plug for this speech-dispatcher-config.
If possible, I’d also like to request that speech-dispatcher-config and process-control auto-connect so that the program works out of the box without requiring the user to run additional commands (Pied is a graphical tool aimed at users who might not be comfortable on the command line).
process-control is used to trigger a restart of the speech-dispatcher daemon after the configuration has been changed.
Hi @MikeSheldon, thanks for the snap and welcome to the forums.
We are usually very cautious before granting write access to files that don’t clearly belong to the snap. In this case given the purpose of the snap is specifically to configure speech-dispatcher I think it seems reasonable though. Personal-files is a super-privileged interface, so publisher vetting will be required if this is approved.
I would ordinarily consider that perhaps a manual connection would be sufficient, but as you point out above users of Pied might not be familiar with the process. It is doable through the snap store gui (rather than the command line), but as this is an accessibility related feature I agree that an auto-connection would be more appropriate. I also don’t think it presents any increased security risk to users above/beyond a manual connection.
The main concern I have is that giving Pied write access to the speech-dispatcher config is the potential for Pied to write incompatible/breaking changes to the config and degrade users’ experience. I’m not familiar with speech-dispatcher at all so unsure how likely this is, but are you committed to maintaining Pied and keeping it in sync with speech-dispatcher? If Pied includes version checking and ensures compatibility with the existing (and new!) configuration files then this is somewhat mitigated.
As an aside, if you could you name the interface dot-config-speech-dispatcher, to conform with the convention outlined here that would be ideal.
Fully understand that you need to be cautious about these things. I wasn’t able to find any details on publisher vetting in the documentation – I found mention of it, but not an explanation of the process itself. This is just being developed by me as an individual, rather than as part of any corporate/commercial project, I don’t know if that is likely to cause any issues with the verification process? (If it helps with credibility, I did work at Canonical from 2014-2017, so there might still be a few people around who can vouch for me on a personal level?)
I’m definitely committed to keeping Pied working with speech-dispatcher. I don’t think this is likely to be a problem though, as the configuration generated by Pied only relies on a small number of speech-dispatcher configuration options (and if those ones were to change, they’d break a lot of people’s configurations). I’ve tested back to speech-dispatcher 0.8.8 (which was released in 2017, and is the version shipped in Ubuntu 18.04), without any issues. I think it’s unlikely that any earlier versions would exist on a system that also has a functional snap install.
However, after giving this some further consideration, I’m going to add a verification step into Pied when the configuration is first changed. This will give the user the option to confirm the change or automatically revert after 30 seconds (similar to a display resolution change confirmation). This would then further reduce the risk of a situation where the user experience is impacted.
I’ve just pushed a change renaming the interface to dot-config-speech-dispatcher, thanks for pointing that out!
That sounds good, thank you. On the basis that you’ll have that config verification then you have a +1 from me. Regarding vetting, once the voting period is over we’ll tally the votes, assuming a positive outcome our advocacy team will do the vetting, which given your history shouldn’t take too long.
Ah sorry, I overlooked the consideration of process-control when I was thinking about the speech dispatcher config files. +1 from me for process-control, the ability to restart the daemon seems entirely reasonable.
Sorry for the delay, I think we miss track of this request when we granted access to the personal-files interface. Could you please confirm if process-control is still required to provide the expected functionality?
As already explained, process-control is needed to reload the configuration, thus it is a +1 for me.
I will wait a few days before making it live just in case that any reviewer has additional considerations, as it seems that we all overlooked the auto-connect request for process-control. I’ll let you know once this goes live.
