Active Settings refactoring done

[Marco Martin]

On Sunday 01 January 2012, Sebastian Kügler wrote:
> Happy new year,
> 
> I'm pretty much done with the work we discussed concerning the Active
> Settings app and infrastructure. To refresh your brain, a few keypoints:
> 
> * Active Settings is a plugin-based shell to display configuration modules
> * Configuration modules are either pure QML packages, for example using
>   KConfig declarative bindings
> * Modules provide optional C++ plugins to implement extensions

a thing that i still wanted to do is to move the more "common" part of the 
polkit implementation of the clock in a global place, to make an api similar 
to the old kcms polkit usage

> * Settings modules can be embedded into apps using a set of declarative
>   imports

+1

> I've moved and refactored most of the guts of Active Settings into its own
> plugin (in plasma-mobile/components/settings, exported as
> org.kde.active.settings. (If that's not a good name to export, we'd better
> change it now.) Code is currently in the sebas/settingscomponent branch in
> the plasma-mobile git repo. From my POV, I'm planning to move this into
> master if nobody screams.

+1 for me, a thing that could be done is to review the public api that goes in 
the import

> The C++ plugins are now pretty lightweight, basically exporting one QObject
> derived class as plugin, and registering one or more QObject-based types to
> the declarative runtime. We get away with minimal build deps here (kdelibs
> plugin macros, KPluginFactory and QObject, so it's very easy to ship
> settings modules individually of our releases.
> 
> The KConfig bindings have not yet seen more work, so nested group support
> is not yet in there. I'll have a closer look at the JS bindings, and will
> try to come up with something compatible to that, I guess.

i think the kconfiggroup of the js bindings are really nice (kconfiggroup is a 
js Object accessible in the usual way with . or []) unfortunately it depends 
on the usual hack that won't work on qml2, so is not really optimal..

> As a result of this refactoring, the active-settings appp is now pretty
> minimal, but sadly needing about 236 lines of C++ just to set the command
> line args as context property. (I haven't found a way to do that inside
> the plugin, and I don't see how it would be possible.) We have a fine
> candidate for a "general app launcher" class here, which encapsulates the
> kdeclarative setupBiindings stuff, and loading a package, probably
> something close to what plasmoidviewer or plasma-windowed does.
> Suggestions welcome, this code is more or less duplicated everywhere in
> plasma-mobile/applications/*.

for this I was thinking to a qdeclarative view subclass that does the job (ie 
just have to do a setPackage(package name) and resolves by itself the main 
script, does the hack etc.

not sure if there are much more things that could be libraryfied

> 
> As a test case for embedding a settings module directly into an app, I've
> implemented an embedded settings module with the browser's dashboard:
> 
great job ;)
as thomas noted is not sure that will work ui wise for all applications, but 
there it seems so.

on the other hand, we should also ensure the side panel of the config app 
won't get too much crowded with an entry for each app.

so what i was thinking about is:

* the apps config that can go in the sidebar are controlled by a whitelist, so 
very tight and very few
* there would be a configure apps entry, that will load a menu nearly 
identical to the top app menu that shows the grid list of only the apps that 
offer a config ui

Cheers,
Marco Martin