Settings infrastructure for handling app/user/system settings
Revisit our current settings infrastructure to store app/user/system to:
* make sure that it is feasible for using it in the Ubuntu Touch project
* make sure that it is ready for a converged world
* make sure that it fits with our app confinement story
Blueprint information
- Status:
- Not started
- Approver:
- Sebastien Bacher
- Priority:
- High
- Drafter:
- Thomas Voß
- Direction:
- Needs approval
- Assignee:
- Sebastien Bacher
- Definition:
- New
- Series goal:
- Accepted for saucy
- Implementation:
- Unknown
- Milestone target:
- None
- Started by
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
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:/
== 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:/
Work Items
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
Dependency tree
* Blueprints in grey have been implemented.