Feat/ui helper

[JarbasAl]

add a new class for consumption by downstream appstore like integrations

companion PR in setup skill OpenVoiceOS/skill-ovos-setup#57

This new class is the central place to manage anything UI related, downstream should not need to import anything else

This allows all sorts of rich integrations by any downstream application, terminal, web, GUI...

initial implementation only for stt and tts, extracted from setup skill. future PRs will add other kinds of plugins

plugin configs are now expected to move UI specific data to a "meta" section, backwards compatibility is provided for existing keys in the wild, this also introduces the concept of an equivalent to skills settingsmeta.json to request additional setup steps

the intention is that this can be directly integrated with this sort of UI MycroftAI/mycroft-core#2698

side note, there are utils to generate settings meta from dicts automatically, this can be used to share the UI for editing mycroft.conf with some extra work for handling edge cases

[codecov]

Codecov Report

❗ No coverage uploaded for pull request base (dev@b23f88e). Click here to learn what that means.
The diff coverage is n/a.

@@          Coverage Diff          @@
##             dev     #85   +/-   ##
=====================================
  Coverage       ?   0.00%           
=====================================
  Files          ?      41           
  Lines          ?    2820           
  Branches       ?       0           
=====================================
  Hits           ?       0           
  Misses         ?    2820           
  Partials       ?       0           

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[JarbasAl]

images of what a UI using this "extra_setup" could look like

[AIIX]

Not sure how this skill settings GUI will help with completely, I thought this was to allow plugins to pre decide and provide a gui specific config coming directly from the plugins that can for example state i have modules and voices vs plugins that state i have only voices for the setup skill GUI list or moving it into a more cleaner nested GUI list, For plugins that provide configs it seems to make sense to have this skill setting GUI applied to them for user facing changes, but i think the pre defined gui config was something very internal to gui building and not user facing

[AIIX]

I have seem to have better solution to the list problem so maybe i don't need to care weather a plugin supports modules or not anymore gui side this seems much cleaner:

[JarbasAl]

Not sure how this skill settings GUI will help with completely, I thought this was to allow plugins to pre decide and provide a gui specific config coming directly from the plugins that can for example state i have modules and voices vs plugins that state i have only voices for the setup skill GUI list or moving it into a more cleaner nested GUI list, For plugins that provide configs it seems to make sense to have this skill setting GUI applied to them for user facing changes, but i think the pre defined gui config was something very internal to gui building and not user facing

as explained several times, this is for a NEW page, for plugins such as polly TTS that require credentials in order to work. it was even you who suggested i called it "extra_setup" in the chat

for the nested list view i did not add anything because that is not yet supported, if you implement it gui side i can add that, as i said i can add any new keys you need

[JarbasAl]

here is how a plugin would provide the metadata for the extra setup page described above https://github.com/OpenVoiceOS/ovos-tts-plugin-polly/blob/dev/ovos_tts_plugin_polly/__init__.py#L235

[AIIX]

here is how a plugin would provide the metadata for the extra setup page described above https://github.com/OpenVoiceOS/ovos-tts-plugin-polly/blob/dev/ovos_tts_plugin_polly/__init__.py#L235

        s = {"key_id": "", 
              "secret_key": "", 
              "region": "us-east-1"}

Is this what the fields need to be generated for ?

[JarbasAl]

here is how a plugin would provide the metadata for the extra setup page described above https://github.com/OpenVoiceOS/ovos-tts-plugin-polly/blob/dev/ovos_tts_plugin_polly/__init__.py#L235

        s = {"key_id": "", 
              "secret_key": "", 
              "region": "us-east-1"}

Is this what the fields need to be generated for ?

for this specific plugin yes, but it could be anything at all that the plugin needs, just like skill settings can be anything the individual skill needs

i suppose some plugins may need quite advanced setups, but the most common case will likely be a couple strings entries for api keys

also note this applies to every plugin supported by OPM, not only TTS and STT, the aim is to have a universal interface for this across all ovos projects

[AIIX]

here is how a plugin would provide the metadata for the extra setup page described above https://github.com/OpenVoiceOS/ovos-tts-plugin-polly/blob/dev/ovos_tts_plugin_polly/__init__.py#L235

        s = {"key_id": "", 
              "secret_key": "", 
              "region": "us-east-1"}

Is this what the fields need to be generated for ?

for this specific plugin yes, but it could be anything at all that the plugin needs, just like skill settings can be anything the individual skill needs

i suppose some plugins may need quite advanced setups, but the most common case will likely be a couple strings entries for api keys

also note this applies to every plugin supported by OPM, not only TTS and STT, the aim is to have a universal interface for this across all ovos projects

apart from setup skill where all does this ui interface need to be displayed ? That determines where the ui generator fields page and field templates pages should live

[JarbasAl]

here is how a plugin would provide the metadata for the extra setup page described above https://github.com/OpenVoiceOS/ovos-tts-plugin-polly/blob/dev/ovos_tts_plugin_polly/__init__.py#L235

        s = {"key_id": "", 
              "secret_key": "", 
              "region": "us-east-1"}

Is this what the fields need to be generated for ?

for this specific plugin yes, but it could be anything at all that the plugin needs, just like skill settings can be anything the individual skill needs
i suppose some plugins may need quite advanced setups, but the most common case will likely be a couple strings entries for api keys
also note this applies to every plugin supported by OPM, not only TTS and STT, the aim is to have a universal interface for this across all ovos projects

apart from setup skill where all does this ui interface need to be displayed ? That determines where the ui generator fields page and field templates pages should live

open question, but my initial inclination is that it should be a PHAL plugin serving any random downstream consumers

any component with a settings page could register with its skill_id and be available via bus api provided by the PHAL plugin, any GUI or terminal app could then use the bus to get a dict of skill_id: settings meta

the display itself is more tricky, the basic usage would have the plugin itself use the GUIInterface class, but things like ovos-shell and setup skill could handle this directly and just tell the plugin to not display if configured as such. like factory reset basically

i think this plugin could provide a native mycroft.conf setup also and perhaps replace the configuration provider plugin, ie, migrate that plugin to use the universal settingsmeta scheme

[AIIX]

here is how a plugin would provide the metadata for the extra setup page described above https://github.com/OpenVoiceOS/ovos-tts-plugin-polly/blob/dev/ovos_tts_plugin_polly/__init__.py#L235

        s = {"key_id": "", 
              "secret_key": "", 
              "region": "us-east-1"}

Is this what the fields need to be generated for ?

for this specific plugin yes, but it could be anything at all that the plugin needs, just like skill settings can be anything the individual skill needs
i suppose some plugins may need quite advanced setups, but the most common case will likely be a couple strings entries for api keys
also note this applies to every plugin supported by OPM, not only TTS and STT, the aim is to have a universal interface for this across all ovos projects

apart from setup skill where all does this ui interface need to be displayed ? That determines where the ui generator fields page and field templates pages should live

open question, but my initial inclination is that it should be a PHAL plugin serving any random downstream consumers

any component with a settings page could register with its skill_id and be available via bus api provided by the PHAL plugin, any GUI or terminal app could then use the bus to get a dict of skill_id: settings meta

the display itself is more tricky, the basic usage would have the plugin itself use the GUIInterface class, but things like ovos-shell and setup skill could handle this directly and just tell the plugin to not display if configured as such. like factory reset basically

i think this plugin could provide a native mycroft.conf setup also and perhaps replace the configuration provider plugin, ie, migrate that plugin to use the universal settingsmeta scheme

The configuration provider PHAL plugin already provides a similar interface for mycroft.conf, so would prefer to have this interface coming from there itself, as it already also includes most of the field building templates needed for this type of UI interface

[JarbasAl]

yes thats what i meant, sorry if it wasnt clear

i meant making the existing configuration provider plugin accept a settingsmeta structure from the bus, this will work for skills or even external apps

but i also think mycroft.conf itself should use settingsmeta.json structure

the ultimate goal here is that every configurable component provides this settings meta and UI can be replaced, here i use UI very liberally on purpose because im thinking about command line only applications etc as well as web applications.