RFC: plasma2 and configuration

[Marco Martin]

On Wednesday 27 February 2013, Aaron J. Seigo wrote:
> > > 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
> 
> this is probably my favourite bit of this approach. we'll just need to make
> sure that the config object gets properly tickled when, for instance,
> javascripts are run via the Desktop Scripting API.

at the moment i see only 2 ways:
a) just config file modifications watching (kconfigskeleton already does it 
iirc) not efficient but works

b) making that config object directly accessible to the desktop scripting api 
(not sure if the latter would require desktop scripting moving to qml's 
javascript instead of qtscript javascript as well)

> how will we keep this consistent between different script engines?
> 
> > > 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)
> 
> how does the scriptengine know what the form factor is? currently that's
> something that is handled by KDeclarative and libplasma .. and it is the

it doesn't really care, because it just takes files from packages, that 
libplasma already takes care of giving the ones from the correct formfactor

> shell that will remain in charge of creating and managing the top level
> views for the UI the AppletScriptEngine powers.
> 
> there is a division of responsibility there, and sticking to it is largely
> why we have been able to move forward without completely rewrites at any
> given point in time. i'd like to keep that feature :)

yeah, right now  the only "fixed" thing is the config dialog being a window. 
if we want to do such that this bit as well is controllable by formfactor, we 
could make it purely a qml object that then it gets passed somehow to the 
shell, that decides wether to create a view, make it inline or anything, i 
don't know how to do it tough.
(there is a lot of separation right now, so the shell and its views doesn't 
really know what AppletInterfaces are, and that is good i think)

> > 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...
> 
> .. which is different fro thoroughly depending on the scriptengine as we
> currently have it.
> 
> > > 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 HTML could well be presented in a QML container (which as you note is
> the current plan) but how will the HTML app:
> 
> * be notified of configuration actions?
> * publish a configuration UI?
> 
> if the idea is that HTML applications must include QML for these parts,
> then we don't really have an HTML app engine but an HTML view in QML :)

the "outer" config ui is qml that comes from the shell anyways, so that can be 
exactly the same.
the config pages instead come from the package, so in theory they could even 
be html pages

this of course depending how useful the webkit bindings will be (and how much 
extra objects we'll be able to bind in wekit's js)

> > only thing it remains to be seen if the kcm window can be embedded in the
> > qml config ui...
> 
> our favourite friend returns -> qwidgets + qml .. :)

with many abuses of
http://blog.qt.digia.com/blog/2013/02/19/introducing-qwidgetcreatewindowcontainer/

i managed to show a qpushbutton over a qquickview.

so that makes possible both things we need:
* qquickview inside qwidgets, for the plasma kpart
* qwidgets inside a qquickview, for kcms inside a qml config dialog (well, 
actually is a qquickview inside a widget, inside another one, that one is 
parent as well of the widget we want to "embed" that is sibling of the view, 
so yes is ugly and pain but works :p)

Cheers,
Marco Martin