Moblin Settings

The driving force behind settings management in Moblin 2.0 is, first and foremost, to make customizing the user experience as intuitive and easy as possible.

Moblin 1.0 used the same strategy as the desktop environment, which was to create a "control panel" region where individual settings binaries were displayed and executed for control of a collection of system tunables. The onus was placed entirely on the user to tune the device beyond the default behavior. In moblin's next generation we want to provide a better behind-the-scenes API to the settings controls so that applications can configure the device automatically.

We also want to make our product as extensible as possible by removing as many dependencies as we can. Our primary output is a single daemon which makes no assumptions about what the GUI will look like (or even that there is a GUI) or what hardware is available. It will simply be a compendium of all the logic needed to setup and tune a mobile device. We will expose a large unified control API through DBUS which relies primarily on application side entities, rather than the user him/herself, to configure the system.

This will require the user to know much less about what's under the hood and enable them to get on with what they want to do. In addition, we in the moblin settings project, can focus purely on functionality, performance, and power, and let the UI designers handle making the user experience smooth and simple.