touchy settings UI architecture

[Sebastian Kügler]

Hey,

Some progress ...

On Friday, October 14, 2011 13:02:19 Marco Martin wrote:
> one of the things is pretty clear we need for Active 2 is a centralized
> settings ui, since systemsettings revealed to be so painful to use on a
> touchscreen  that is now blacklisted (and 99% of its kcms wouldn't be
> useful)

I've implemented the basic shell last weekend, and actually got quite far. 
Let's see what's working, and how the whole thing looks like:

* There's a new application, active-settings, much like the browser, 
  imageviewer, about app

* There's also a new plugin type, Active/SettingsModule, this is basically the 
  equivalent of a  KCModule. It consists of a QML package and an optional C++ 
  library derived from the SettingsModule class.

* active-settings (AS) loads a QML package that has the basic shell body, 
  including a listview of the available modules, and an Item which is used to 
  load the actual settings module into, let's call this Settings.qml

* A model with the available modules is exported to Settings.qml which serves 
  as a base for choosing the module to load. This model only has metadata, 
  such as name, description and pluginname

* Settings.qml, when a module is chosen asks the C++ part to look for a plugin 
  library (defined in X-KDE-Library), if such a plugin exists, the C++ part 
  exposes a settings object (e.g. TimeSettings) to the QML part which can be 
  instantiated there. If it doesn't exist, the module is assumed to be QML 
  only.

* There are two examples installed right now, both not functional but showing 
  that the basic plugin loading mechanism works: Time Date and Web Browser    
  settings. The Time and Date thing uses a C++ module, as part of the plugin 
  and exposes a few settings. (Just reading right now, writing not done yet.)

* The web browser settings module is just a more or less empty QML package.

That's roughly it. Of course this means that we now have to write settings 
modules, that the SettingsModule class should probably move into some kind of 
lib, but the basics are in place.

It also struck me that we have no guideline how to set up a UI. Not that I've 
gotten to this yet, but it's probably something we need to work on in the 
future.

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9