(2014-03-10, 12:18)pvagner Wrote: If possible I would again bring up the original discussion where we were talking about how to retrieve needed info from the XBMC.
I think info labels are good while retrieving items from the file list, from the list of videos, audio tracks in a media library so at the end we will be able to override it for a particular content. As an example I can remember the timeline view of EPG events in the PVR. On the screen we have all the labels but the only focusable control are individual show names. Using info labels we may be able to speak other details.
As for the other windows e.g. home screen, settings screens, OSD menus etc we are using hardcoded ID mappings to their names. It may bring localization issue that we may need to localize these seperatelly from the main XBMC localization.
Well window names are not all available programmatically, and are not localized in XBMC in any case. I plan on localizing them in the addon in the future. I'm still in a sort of exploratory mode and much of the code may change. I tend to wait till things 'settle down' and then localize strings so I don't have to keep changing the localization strings when I change other things.
As for other elements what could be done is to reference the ID of the the item with a label in a map instead of hard coding a localized string. I think I could change the tables in skintables.py to use this sort of method instead. It would be nice to avoid mappings like this altogether, but not all controls that are 'connected' visually have that connection accessible through code, plus different skins use widely different layouts.
(2014-03-10, 12:18)pvagner Wrote: Isn't the JSON RPC API better for this? It can return text of all the focusable controls this way. If nothing else this can be used as a fallback.
I'm not sure that there is any info relevant to this that you can get with the JSON RPC API that you can't get with infolabels. I just find infolabels less cumbersome to work with
I've used the JSON RPC API in the past when I needed to, but I find the documentation tends to be unclear, and that has made me less inclined to use it when there is an easy alternative.
(2014-03-10, 12:18)pvagner Wrote: I am going to try adding my favourite tts backends and then I'll be able to test more.
If you get anything working, I'd love to add it to the current backends in the addon.
The biggest obstacles I'm considering right now are:
- Accessing the text of controls without IDs
- XBMC Settings views. Much of this is dynamically generated and harder to get info from.
- Interrupting speech when a control is changed. Right now the current phrase has to finish before the next one can start.
- I'd like to get speech available on all major platforms. ATV2 has already proven difficult and android probably will as well.
Right now I think I'm going to concentrate primarily on accessing all the elements of the main interface and secondarily on more general access to addons and such.
I'm going to focus on making the addon work well with the Quartz skin, because it has simpler layout and I think focusing on one skin initially will be the fastest route to a usable interface.
On a side note, I'm thinking it would be useful have this addon provide a module so other addons could easily add speech, even for non-accessibility uses.
So an addon could:
Code:
import xbmctts
xbmctts.say('download finished')