RFC: plasma2 and configuration

[Aaron J. Seigo]

On Tuesday, February 26, 2013 17:54:18 Marco Martin wrote:
> * everything regarding configuration uis goes away from libplasma

define "everything". there are four aspects to configuration:

0. the actions that trigger showing configu UI
1. notifying the component (e.g. plasmoid) that configuration has completed
2. creating and showing the actual window the config appears in
3. the control UI inside the window (Ok/Cancel, etc)

where these should be implemented is critical as it will allow (or deny) new 
device adaptations, future flexibility with script engines, etc. iow, if we do 
not get this right, the work we're doing now will fail to meet the goals that 
got us started on this approach.

one thing we need to avoid is reimplementing libplasma in the QML script 
engine. this will make any future scriptengine work far, far more work and 
will essentially make it impossible to support things like HTML5 applications.

the division of labor might look like:

0. libplasma
1. the scriptengine (though this depends on 3, so probably via libplasma)
2. the shell. (otherwise it will become QML dependent. and how does HTML5 work 
then?)
3. libplasma? it needs to be consistent between script engines, but possibly 
vary between shells.

> * the plasmoid may offer in their config directory a list of desktop files,
> one per category, that would tell the name of the category, icon,
> kconfiggroup and qml file to load

how about a model driven mechanism instead? each configurable plasmoid could 
contain a QML component that provides a model in which each entry is a 
configuration page. translation would be handled in the normal fashion; support 
for kcm pages would be easy enough; would only require reading in one file and 
it could use laoders extensively to keep performance up.

> * All configuration for applets based upon ConfigLoader, only one config.xml
> per plasmoid, supporting multiple config groups

this requires that ConfigLoader can create configuration structures from 
templates. otherwise how does one do something as simple as a launcher where 
each entry has its own configuration data (or group)

right now, ConfigLoader (because it is a KConfigSkeleton) also requires that 
*all keys* have names that are unique in the ConfigLoader. that means that 
while they appear in different groups, they need unique names. that seems very 
awkward for anything moderately complex, and suggests to me we need a proper 
per-group API for KConfigSkeleton and ConfigLoader.

> * one config group per page

why?

this would mean that the UI must match the configuration structure as stored on 
disk, and we know that "interface follows implementation" is a trap.

what about pages with multiple config groups, as in the launcher example above?

> * eventual extra config pages, like global shortcuts will be provided by the
> shell package, because is not something applets should directly care about

kcm's? this is an existing use case that we need to provide for unless we 
commit to reimplementing all the kcm's in qml :)

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20130226/8e928011/attachment.sig>