RFC: plasma2 and configuration

[Marco Martin]

On Tuesday 26 February 2013, Aaron J. Seigo wrote:
> 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:

err, yeah, the creation, instantiation and destruction of the config dialog i 
mean ;)

> 0. the actions that trigger showing configu UI

the action itself is still in Applet, it probably should stay here?

> 1. notifying the component (e.g. plasmoid) that configuration has completed

I have an object exposed by the plasmoid, ConfigPropertyMap that is a 
qqmlpropertymap, ie property bindings work with its values, so that would look 
like "automatic" without need for configChanged() event listener

> 2. creating and showing the actual window the config appears in

done at the moment by the scriptengine

> 3. the control UI inside the window (Ok/Cancel, etc)

window close is done at the moment, exposing the config window object to the 
context of the qml in the dialog (not exposed to the context of the rest of 
the plasmoid tough)
 
> 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.

for how i tought for the moment, it is done pretty much all (with all=the ui 
creation part) by the scriptengine, it has a pro, a big flexibility for 
formfactors (only constrain is that the config dialog is a different window, 
but the actual ui can be anything)
as con is that indeed, it depends from the scriptengine, so makes harder to 
have another scriptengine in the future, but we are thoroughly depending from 
qml for the ui anyways...

> 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.

didn't we said that html plasmoids pretty much become qml plasmoids that just 
have a webkit scroll view and nothing else? (the package would contain only 
html, that html viewer qml ui would be loaded from another package)

> 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.

ok, so, only one "main" config qml per package, (maybe even always called 
"config.qml" or someting) this gets loaded and parsed as soon as the config ui 
opens, but in turn it just provides a model of components coming from other 
qml files that would be instantiated only when needed. didn't think about 
that, will try it now ;)

> > * 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?

yeah, point, was a bit of overengineering probably.

> > * 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 :)

the kcm may be instantiated when a particular keyword (like kcm_pluginName or 
something like that) instead of a component is present in the model for a page

only thing it remains to be seen if the kcm window can be embedded in the qml 
config ui...
in the end both should be a qwindow, so shluld be possible.

Cheers,
Marco Martin