Guts of active-settings

[Sebastian Kügler]

Hi Ben,

Thanks for your input.

On Friday, December 23, 2011 01:37:41 Ben Cooksley wrote:
> On Wed, Dec 21, 2011 at 1:51 AM, Sebastian Kügler <sebas at kde.org> wrote:
> > [CC:ing Ben Cooksley, systemsettings maintainer, as he'll much like have
> > ideas or concerns around it.]
> > 
> > In this email, I'm explaining a bit how the active-settings app works,
> > and how it can be extended, and how it should be used.
> > 
> > Please also take note of my earlier email about QML bindings for
> > KConfigGroup, which seeks a better solution for the configuration
> > reading and writing mechanism we're using internally.
> > 
> > Alrightie, so active-settings is a small QML shell (Active App) that
> > hosts configuration models. It's basically kcmshell4 / Systemsettings in
> > a QML world. It's of course designed for touch devices, it uses the
> > Plasma QML Components (so it adapts itself to the type of device it's
> > run on, currently touch or desktop).
> > 
> > Upfront: Existing KControl KCMmodules do not work in active-settings,
> > it's a conscious depart from the world of QWidgets, and I'd really like
> > it to become less of a monster than systemsettings.
> 
> I guess you are referring to the modules themselves here, as they are
> a little bit of a mess. The app itself is fairly cleanly coded though
> 
> :)

Yes, I was talking about the modules, and with "mess" I was mostly refering to 
the "wealth of features", which is a bit overwhelming. Indeed, PA will have a 
lot less to configure.

> > On startup, active-settings queries KServiceTypeTrader in order to look
> > for plugins that have the type "Active/SettingsModule". These plugins
> > provide a QML package with the UI for the module, and an optional C++
> > library to load. The QML UI is loaded in the "content" part of the
> > active-settings app, active- settings exposes a few things to it, such
> > as bindings for KConfigGroup. (This restricts usage of those bindings to
> > modules run inside active-settings, which is I think a sensible
> > restriction.
> 
> Even though a tablet or phone has much less to configure you are still
> likely to run into the need to group certain panels, so I would
> recommend coming  up with standards on how configuration panels are
> grouped.

You mean UI-wise or technically? In principle I agree, but then, hopefully we 
can delay the need for grouping for as long as possible -- by only having 
essential modules in there.

I'm working on a way to embed these modules in application, so maybe we end up 
putting most of them inline into an application (sounds like a sensible thing 
for the browser, for example).

> This is something that really does need a usability expert, and is
> something System Settings itself has never really gotten.

Yes, I agree, many have tried though =) (Which is just to say that it really 
is not an easy problem to solve.)

> > It would also be cool, if we had an easy way to offer this kind of
> > functionality to apps (so one can, in pure QML) write a configuration
> > interface for ones app -- either by starting active-settings
> > org.kde.active.settings.mycoolapp, or by embedding it somehow. (The
> > former of course needing a mechanism to sync config across processes.
> > Specific modules can be opened right away, by using the plugin name of
> > module as argument to active-settings, much like kcmshell4. (It
> > currently lacks the --list argument, though.)
> 
> One question: given that QML is supposed to be the future of Qt based
> interfaces (with just the QML changing as the form factor changes)
> perhaps it might be worth looking at how KCModule can be tidied up
> (considering it is practically untouched since KDE 3 times) to
> accommodate QWidget and QML based modules (as there is no point in
> duplicating work, and i'm sure some things will bleed across between
> Plasma Active and other form factors including the desktop)

I think it would become really ugly, as the KCModule in the end does 
completely different things. Basically, in the QML world, it's a declarative 
component with some stuff exported (bindings for KConfigGroup, for example), 
there's no save buttons, no revert settings (at this point), so actually most 
of KCModule won't be very useful. In the new design, we get away without a 
dependency on QtGui, which is also very desirable. I'll have another look 
though if code can be shared somehow among those two.

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9