Settings infrastructure for handling app/user/system settings

2013-03-25 meeting notes:

What does the API stability means for system settings?
- apps are going to be written against the current api, we need to make sure we keep that compat

Architecture:
- one proposal was to abstract the settings behind indicators

Low level implementation:

User/system settings?
Per application settings

Per application:
- was not discussed/covered yet

Do we need to sync app settings over devices:
- likely not for v1

What's the plan for a system setting UI? mpt is actively working on it

Which settings are for all users, or the current user?

Which APIs do apps use to store their own settings?

Can apps integrate their settings with a standard settings app?

Permissions to access various settings?

What happens to settings when apps are removed?

Can settings be synced across devices?

Updated/versionned keys:
- we don't have a good story for app-keys

https://blueprints.launchpad.net/ubuntu/+spec/indicator-backend

== Backends and internal interfaces for system settings ==

Currently implemented or being implemented in Touch images:
 * indicator services as daemons (main internal interface)
 * dconf storage for some settings
 * Systemd DBus interfaces for some system services

Needs a public API for apps

== Apps APIs related questions ==

 * permissions to access system settings
 * app API to access user settings, system settings, private settings (visible only to the app)
 * addition of app-specific settings to the settings app
 * API stability, including stability of the settings themselves

XXX can we use QSettings to expose these? or are these just meant for per-app settings?

== DConf ==

 * used heavily in current settings implementation
 * system dconf settings used by many GNOME apps, but not that many settings so could implement a bridge:
   * proxies
   * locale
   * desktop background
 * has dconf-qt API

XXX is there a DConf QSettings backend?

If we go with exposing DConf to apps, we need an app containment story for it.

== List of official and standard settings ==

 * system settings
 * per-user settings

== Convergence requirements ==

These are typical corporate requirements that need to be implemented or replaced for the converged stack story:
 * override settings (force settings to a value)
 * override default (provide a replacement default)
 * user settings profiles giving more permissions

Sample settings this is enforced on:
 * force screensaver on
 * can't remove items from launcher

== Settings app ==

 * Replacing GNOME Control Center progressively
 * Adapts to form-factor for phone, tablet and desktop

== Design and User Experience ==

 * Want to review list of settings exposed for this or that form-factor
 * Layout / presentation on various form-factor
 * Links between settings?
 * Presenting "settings" both in indicators and settings app?

Designs are being done on https://wiki.ubuntu.com/SystemSettings

Work items:
[seb128] work with design team and engineers to build the list of "system settings" we will need: DONE
[thomas-voss] figure out if we need a system settings app for the phone and who is owning the topic: DONE
[seb128] work with design team to get directions on how settings are laid out on various form-factors, how indicators settings are presented in the settings app, link between settings etc.: INPROGRESS
[seb128] identify and implement any missing backend interfaces for all system settings we want: INPROGRESS
[thomas-voss] check with the SDK team what's the story for schemas on the QML side, QSettings DConf backends, DConf usage etc.: INPROGRESS
[thomas-voss] discuss apps APIs for settings with lool: TODO
[ted] get the indicators/system settings summary of the start of the meeting written down in the wiki: TODO
[thomas-voss] talk to lool about the polkitd on the phone: TODO
[seb128] discuss polkit, dconf, app confinement etc. with security team: INPROGRESS