+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: Add-on Support (https://forum.kodi.tv/forumdisplay.php?fid=27)
+---- Forum: Service Add-ons (https://forum.kodi.tv/forumdisplay.php?fid=152)
+---- Thread: Release Kodi Screen Reader (Text to speech) (/showthread.php?tid=196757)
RE: Kodi Screen Reader (Text to speech) - leonardder - 2015-12-30
Have been thinking about an alternative for the dummy addon approach, which is slightly ugly honestly. Found two so far:
1. Check whether addon is installed into special://xbmc rather than special://home. If so, install keymap and disable at first run.
2. Prefered: Check whether (special://xbmc|special://home)/addons/service.xbmc.tts/firstrundisable exists. If so, install keymap and disable at first run.
RE: Kodi Screen Reader (Text to speech) - ruuk - 2015-12-30
(2015-12-30, 18:26)leonardder Wrote: Have been thinking about an alternative for the dummy addon approach, which is slightly ugly honestly. Found two so far:
1. Check whether addon is installed into special://xbmc rather than special://home. If so, install keymap and disable at first run.
2. Prefered: Check whether (special://xbmc|special://home)/addons/service.xbmc.tts/firstrundisable exists. If so, install keymap and disable at first run.
I was thinking about this while I was at work and came up with option 1 myself only to now see you also came up with it
I prefer option one, possibly with the inverse of option 2 as well. I think if the addon is included in a build it should be disabled by default, but there may be some cases where it is otherwise, such as if there is a build that is meant specifically only for the blind. In this case perhaps it perhaps makes sense to have a file in the addon with a switch in it. For instance a file called pre_installed_settings.json with a line like { "enabled": false} in it. The idea being if you are going to be modifying the addon itself anyway, you might as well have it be obvious what what needs to be done - and this method hardly needs any explanation.
On the other hand, the original idea of having the flag be a dummy addon was to have it be outside the addon. This would allow the maintainer of the build to drop new versions in without having to modify anything. So perhaps the enable flag could still be external to the addon. And it doesn't have to be a dummy addon, it just needs to be in a place the addon can reliably find it no matter what platform it's installed on.
I think for now I will implement the check of whether the addon is installed in the system path vs. home and disable it if it is and fix the items that are broken when it is installed this way. I can leave the enable flag method for now while I think about and research what will work best. But if you have some more ideas on this or find some fault in my logic, feel free to say so
RE: Kodi Screen Reader (Text to speech) - leonardder - 2015-12-30
ruuk Wrote:I prefer option one, possibly with the inverse of option 2 as well. I think if the addon is included in a build it should be disabled by default, but there may be some cases where it is otherwise, such as if there is a build that is meant specifically only for the blind. In this case perhaps it perhaps makes sense to have a file in the addon with a switch in it. For instance a file called pre_installed_settings.json with a line like { "enabled": false} in it.
This sounds quite good to me
ruuk Wrote:On the other hand, the original idea of having the flag be a dummy addon was to have it be outside the addon. This would allow the maintainer of the build to drop new versions in without having to modify anything. So perhaps the enable flag could still be external to the addon. And it doesn't have to be a dummy addon, it just needs to be in a place the addon can reliably find it no matter what platform it's installed on.
As a package maintainer, it is perfectly possible to add a package specific file with a flag to the addons directory. I don't get entirely why that file should be outside of the addons structure for that.
ruuk Wrote:I think for now I will implement the check of whether the addon is installed in the system path vs. home and disable it if it is and fix the items that are broken when it is installed this way.
Fine, so I will get rid of that dummy addon then.
RE: Kodi Screen Reader (Text to speech) - ruuk - 2015-12-30
(2015-12-30, 20:51)leonardder Wrote:I may be missing something but what I meant was, if the flag is in the addon (ie. somewhere in the service.xbmc.tts directory) then when you replace that directory you have to re-add that flag. If it is outside that directory, this would not be necessary.ruuk Wrote:On the other hand, the original idea of having the flag be a dummy addon was to have it be outside the addon. This would allow the maintainer of the build to drop new versions in without having to modify anything. So perhaps the enable flag could still be external to the addon. And it doesn't have to be a dummy addon, it just needs to be in a place the addon can reliably find it no matter what platform it's installed on.As a package maintainer, it is perfectly possible to add a package specific file with a flag to the addons directory. I don't get entirely why that file should be outside of the addons structure for that.
RE: Kodi Screen Reader (Text to speech) - leonardder - 2015-12-30
(2015-12-30, 21:09)ruuk Wrote:(2015-12-30, 20:51)leonardder Wrote:I may be missing something but what I meant was, if the flag is in the addon (ie. somewhere in the service.xbmc.tts directory) then when you replace that directory you have to re-add that flag. If it is outside that directory, this would not be necessary.ruuk Wrote:On the other hand, the original idea of having the flag be a dummy addon was to have it be outside the addon. This would allow the maintainer of the build to drop new versions in without having to modify anything. So perhaps the enable flag could still be external to the addon. And it doesn't have to be a dummy addon, it just needs to be in a place the addon can reliably find it no matter what platform it's installed on.As a package maintainer, it is perfectly possible to add a package specific file with a flag to the addons directory. I don't get entirely why that file should be outside of the addons structure for that.
The current process for package building for OSMC is as follows in a build shell script:
1. download the addon source
2. extract it to files/usr/share/kodi/addons/service.xbmc.tts
3. Run dpkg_build files/ package.deb
So, it is as simple as inserting a step after 2, echo "something" > files/usr/share/kodi/addons/service.xbmc.tts/file. Than, the file with the flag is packaged with the addon. When a new version is installed using a replaced package, that package will also contain the new flag. When someone deletes the package, the flag also is removed from the system.
Only thing I do not yet know which might object this above point is when kodi updates the addon. I don't know whether kodi is allowed to update addons in the special??xbmc folder. If so, does it replace the service.xbmc.tts folder entirely?
RE: Kodi Screen Reader (Text to speech) - ruuk - 2015-12-30
(2015-12-30, 21:21)leonardder Wrote:When Kodi updates the addon, the new version goes with the addons in the user's kodi directory. I'm pretty certain the pre-installed version remains but is then unused. This will not be a problem, because we only care about first run anyway.(2015-12-30, 21:09)ruuk Wrote:(2015-12-30, 20:51)leonardder Wrote: As a package maintainer, it is perfectly possible to add a package specific file with a flag to the addons directory. I don't get entirely why that file should be outside of the addons structure for that.I may be missing something but what I meant was, if the flag is in the addon (ie. somewhere in the service.xbmc.tts directory) then when you replace that directory you have to re-add that flag. If it is outside that directory, this would not be necessary.
The current process for package building for OSMC is as follows in a build shell script:
1. download the addon source
2. extract it to files/usr/share/kodi/addons/service.xbmc.tts
3. Run dpkg_build files/ package.deb
So, it is as simple as inserting a step after 2, echo "something" > files/usr/share/kodi/addons/service.xbmc.tts/file. Than, the file with the flag is packaged with the addon. When a new version is installed using a replaced package, that package will also contain the new flag. When someone deletes the package, the flag also is removed from the system.
Only thing I do not yet know which might object this above point is when kodi updates the addon. I don't know whether kodi is allowed to update addons in the special??xbmc folder. If so, does it replace the service.xbmc.tts folder entirely?
Also, regarding your above example, you would ideally remove the files/usr/share/kodi/addons/service.xbmc.tts directory before extracting the new copy. Of course if the tree is created fresh each time, then this would not be necessary. In any case, I can see that where the flag is located doesn't much matter in your process. Where it would matter, as an example, is if someone was maintaining a build with git and was updating the addon via a subtree merge.
RE: Kodi Screen Reader (Text to speech) - ruuk - 2016-01-01
leonardder: I've written all the code, but it turns out you can't disable an add-on that is pre-installed. Probably I'll have to move away from actually disabling the addon and just flagging it disabled so that when it is started it just reads the flag and exits.
So it turns out there is a little more work involved than I planned
RE: Kodi Screen Reader (Text to speech) - ruuk - 2016-01-01
leonardder: Just about done I think, but I'm off to sleep. Some more testing tomorrow and hopefully I'll have something ready
RE: Kodi Screen Reader (Text to speech) - leonardder - 2016-01-01
Sounds good Ruuk. Looking forward to post something working to the OSMC developers.
v1.0.6b1 - ruuk - 2016-01-02
Added a new beta version to my repository: 1.0.6b1.
You can also get it or the repository from the Downloads Page.
Changes:
- Add Dutch translation - thanks to leonardder
- Automatically disable if pre-installed
- Fix issues playing informational sounds when addon is pre-installed
- Add ability do enable/disable addon when it's pre-installed
leonardder: Let me know how this works for you.
Everyone else: Let me know if the changes cause any issues.
If all is well I'll push this to the Kodi repo.
RE: Kodi Screen Reader (Text to speech) - leonardder - 2016-01-04
@Ruuk: It seems that all works quite well except for one thing. When I switched from addon in special://home to special://xbmc, the sounds didn't play until I removed the addon settings from my user data.
One another issue i experience with this version and older versions, which is not related to the new features: It seems that the screen reader doesn't read certain list boxes in the screen reader configuration itself, like the selection box for the espeak voice as well as the audio player to pipe the speech into. Strange enough, the interface listbox works as expected.
RE: Kodi Screen Reader (Text to speech) - leonardder - 2016-01-04
OSMC users, feel free to test:
# wget https://dl.dropboxusercontent.com/u/59700862/mediacenter-screenreader-osmc.deb
# dpkg -i mediacenter-screenreader-osmc.deb
Make sure to delete /home/osmc/.kodi/addons/service.xbmc.tts.
Package currently doesn't depend on any TTS engine, however it recommends espeak and suggests flite, festival and speech-dispatcher. Whenever it is included in OSMC, I will try to have espeak installed by default.
RE: Kodi Screen Reader (Text to speech) - ruuk - 2016-01-04
(2016-01-04, 11:55)leonardder Wrote: @Ruuk: It seems that all works quite well except for one thing. When I switched from addon in special://home to special://xbmc, the sounds didn't play until I removed the addon settings from my user data.I'll fix that when I next get a chance. though it shouldn't be an issue from a user perspective.
(2016-01-04, 11:55)leonardder Wrote: One another issue i experience with this version and older versions, which is not related to the new features: It seems that the screen reader doesn't read certain list boxes in the screen reader configuration itself, like the selection box for the espeak voice as well as the audio player to pipe the speech into. Strange enough, the interface listbox works as expected.I'll take a look at that. I'm heading out to Vegas for CES today, so I'll be busy most of the week
RE: Kodi Screen Reader (Text to speech) - Traker1001 - 2016-01-05
(2016-01-04, 19:34)ruuk Wrote:(2016-01-04, 11:55)leonardder Wrote: @Ruuk: It seems that all works quite well except for one thing. When I switched from addon in special://home to special://xbmc, the sounds didn't play until I removed the addon settings from my user data.I'll fix that when I next get a chance. though it shouldn't be an issue from a user perspective.
(2016-01-04, 11:55)leonardder Wrote: One another issue i experience with this version and older versions, which is not related to the new features: It seems that the screen reader doesn't read certain list boxes in the screen reader configuration itself, like the selection box for the espeak voice as well as the audio player to pipe the speech into. Strange enough, the interface listbox works as expected.I'll take a look at that. I'm heading out to Vegas for CES today, so I'll be busy most of the week
Ruuk, Thank you for everything.
I am jealous that you are going to CES.
Wish I could go.
RE: Kodi Screen Reader (Text to speech) - Bladesftp - 2016-01-25
Hi i am blind and want to use tts on my android is this likely to be available soon
Cheers