Guts of active-settings

[Carl Symons]

On Fri, Dec 23, 2011 at 1:40 AM, Sebastian Kügler <sebas at kde.org> wrote:
> 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 suspect I'm closer to than most here to the uninformed, just make it
work user.

I'm fine with System Settings in 4.7.4. When all else fails, the
search function works fine. The real novices that I work with have
almost no need for System Settings. I helped them get things working
right; they don't know or care about changing the settings.

When I upgraded to PA2, System Settings didn't work as they did
previously, and as I'm accustomed to working on Plasma Desktop and
Netbook. With Ben's help, I found out that it's probably broken for my
tablet. But I also found out that the AppLaunch search worked kinda
like System Settings search. And I've been able to do settings tasks
fine. Then it occurred to me that this might be by design...and it
made perfect sense.

Carl

>
> 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
> _______________________________________________
> Active mailing list
> Active at kde.org
> https://mail.kde.org/mailman/listinfo/active