[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-active
Subject:    Re: Guts of active-settings
From:       Ben Cooksley <bcooksley () kde ! org>
Date:       2011-12-23 0:37:41
Message-ID: CA+XidOHf2WAwOfu_v_47kWAjQrYF-zG1Q27hi84GB9virqKozg () mail ! gmail ! com
[Download RAW message or body]

On Wed, Dec 21, 2011 at 1:51 AM, Sebastian K=FCgler <sebas@kde.org> wrote:
> Hey all,

Hi Sebas,

>
> [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, an=
d how
> it can be extended, and how it should be used.
>
> Please also take note of my earlier email about QML bindings for KConfigG=
roup,
> 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, curren=
tly
> 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 be=
come
> 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
:)

>
> On startup, active-settings queries KServiceTypeTrader in order to look f=
or
> 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 lo=
ad.
> The QML UI is loaded in the "content" part of the active-settings app, ac=
tive-
> 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.

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

>
> The C++ library (which is basically a QObject) has the role to expose the
> "more complicated stuff needed" to the QML module. Imagine reading special
> values from C++ libraries, doing KAuth magic to apply settings, basically
> anything that cannot be done, or is really hard / ugly to do in QML. If y=
ou
> don't need C++ for the guts of your module, just don't add such a library=
. If
> there is already one, you can specify its name in your metadata .desktop =
file,
> so re-using these things is rather easy. (Of course, these would need to =
be
> installed.
>
> An example for a pure QML module is the webbrowser config, found in plasm=
a-
> mobile/applications/settings/modules/web. An example for a module with C++
> part is the time configuration, under modules/time.
>
> The QML parts of those modules are of course Plasma::Packages.
>
> For the "shell" app, it's using a PageStackWindow, which right now has so=
me
> kind of "tab bar" on the right. This "overarching layout" might look diff=
erent
> on a smartphone or smaller screen device in the future, transparant to the
> module. The modules would need to take care of not using too much horizon=
tal
> space (so they'd fit on a smartphone's screen), and be flickable vertical=
ly.
>
> As this is essentially important Plasma Quick API, I'm interesting in
> suggestions for improvements, and of course review of the actual code and
> concepts, so we can start pushing it as "this is how you do config" to app
> developers.
>
> 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 forme=
r of
> course needing a mechanism to sync config across processes. Specific modu=
les
> 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 argu=
ment,
> 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)

>
> Cheers,
> --
> sebas
>
> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9

Regards,
Ben
_______________________________________________
Active mailing list
Active@kde.org
https://mail.kde.org/mailman/listinfo/active
[prev in list] [next in list] [prev in thread] [next in thread]