Add settings support

[joerick]

Should be as simple as possible, providing that:

1. Settings can be stored within the app bundle. This is so settings can be configured in Tide and then uploaded.
2. Configured using a text editor, but later with a Desktop GUI, then later with a Tingbot GUI
3. Because they need to be adaptable to text or GUI usage, a schema should be defined in the app. This will also allow defaults to be defined in the app.

[joerick]

I'm imagining an API like-

Accessing settings

I think a settings object would be the simplest.

screen.text('This is my favourite color', color=settings.FAVORITE_COLOR)

All-caps feels natural to me, but it might be unexpected/ugly? Otherwise:

screen.text('This is my favourite color', color=settings.favorite_color)

Definition of a setting

Have a few choices here. Could configure in Python, writing in main.py something like

settings.define_option(
    'FAVORITE_COLOR',
    display_name='Favourite color', # optional- for GUIs
    type='color',
    default='red')

However the GUIs might have a hard time pulling these definitions out of the code. There are probably some clever solutions - AST parsing, or using a dummy tingbot library that stubs out everything but registering settings. Could be confusing though?

A more 'dumb' file format is another option. e.g. JSON

_settingsdefinition.json

{
  "FAVORITE_COLOR": {
    "type": "color",
    "display_name": "Favourite color",
    "default": "red"
  }
}

settings.json

Then we have the user-defined settings file. This would be .gitignored by app developers to avoid sensitive info (e.g. API keys) going public.

settings.json

{
  "FAVORITE_COLOR": "green"
}

Thoughts welcome!

[mansj]

I like this. A separate .json-file feels best, and we should be able to write to the settings from an app as well.

settings('FAVORITE_COLOR') = 'red'

[joerick]

What would be your use-case for writing settings from the app @mansj ?

[mansj]

@joerick Having a user choosing things in the app, using the touch screen, and storing it for future use. Upon first launch ask the user a series of questions and store the answers as settings.

[furbrain]

I think I would implement this as follows; Setting a default value - should come first in main.py tingbot.default_settings = { 'favourite_colour':'blue', 'year_of_birth':1976, }

Accessing a setting: print tingbot.settings['year_of_birth']

Changing a setting: tingbot.settings['favourite_colour'] = 'red'

Behind the scenes, tingbot-python would use the default_Settings as an initialiser, and read in settings.json the first time tingbot.settings is initialised. Every time tingbot.settings is assigned to it will update the on-disk file. So basically tingbot.settings will act like a standard dict. This should be pretty easy to implement - if you're happy I may be able to get it done this pm.

[joerick]

I like the simplicity/consistency of this approach @furbrain, but can we do a GUI integration with this system?

[mansj]

The only thing I would worry about with @furbrain :s approach would be that it seems a little bit "too easy" to overwrite the settings that way.

[joerick]

@mansj if the settings can be changed in the app, this raises an interesting problem - the settings can be changed both in Tide on the computer and on the Tingbot. So how do we decide whether to overwrite settings on the Tingbot when uploading a new version of the application? You have the choice of overwriting changes on the Tingbot, or ignoring changes made in Tide when uploading the app... Hmm :/

[mansj]

@joerick Merging would probably be the only "right" way to do it - add new settings not already in the tingbot app local setting, and keep old ones.

[furbrain]

@joerick @mansj I've put a first draft at settings in as a pull request. I've got three sources for settings - default_settings.json, gui_settings.json and local_settings.json. If changes are made within the app, these are saved into local_settings (but if something is not changed programatically, it is not saved). So we can update default_settings or gui_settings, and these would be updated in the app, without overwriting anything set locally. Does that make sense? Have a look at settings.py in #22 - look specifically at setitem, getitem, load and save

[joerick]

Implemented in #22