RFC: plasma2 and configuration

[Aaron J. Seigo]

On Tuesday, February 26, 2013 19:31:52 Marco Martin wrote:
> 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?

i think so, yes ...

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

> > 2. creating and showing the actual window the config appears in
> 
> done at the moment by the scriptengine

to me, this seems like something that belongs to the shell as it knows about 
the top level windows and form factor appropriateness.

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

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

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

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

-- 
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/20130227/fbbb1b4e/attachment.sig>