[KDE/Mac] systemsettings, kde-cli-tools and other plasma components on non-Plasma/non-X11 platforms

[René J.V. Bertin]

On Thursday December 24 2015 12:15:59 John Layt wrote:

> Akademy a few years back. The general consensus was that forcing
> Mac/Windows/Gnome users to install Systemsettings just to configure their
> standalone app was A Bad Thing (TM) and shouldn't be done. It required
> specialised knowledge of what to do and where to look that we couldn't
> expect from new users or users of other platforms. Installing a 'KDE
> Settings' module in the host settings program (Mac System Preferences or
> Windows Control Panel) was also ruled out for the same reason: what new
> user knows to go there, or even knows the app comes from KDE?

That's way too disdainful of new users to me. Combined with something like an overshot assumption that the don't know how to RTFM and that it'd be unacceptable to tell them to.
That same reasoning can also be applied to SystemSettings on a Plasma desktop, and even more so to the GTk KCM...

I won't deny that such users probably exist, but those are the ones for whom we provide sensible defaults that don't require them to go anywhere near a settings panel.

Evidently an entry in the host's control panel has to indicate clearly what it does.

A quick look at my own System Preferences window shows a number of entries that were installed by 3rd party applications, including Flash Player, Flip4Mac and Java. They all have in common that they control settings that cannot be accessed in a sensible way through individual applications.

> The user's
> mental model is they are not configuring a desktop or group of apps from
> the same 'manufacturer', but rather they are configuring a single app they
> have downloaded and installed.

That would depend on how the application is installed, but even then there are families/suites of applications that will want to share certain settings. Of course somebody building a standalone version app bundle can go further in providing sensible defaults that alleviate the need for configuring.

> KCM modules are split out correctly. What needs doing is to determine what
> KCM's are needed by apps on other platforms and to ensure these are
> installable separately from Systemsettings so the devs and packagers can
> pull them in as required.

That is actually already the case for the largest part of KCMs ... and annoyingly they're in a package that makes it even less easy to install them.

> can't use the host config then embed the KCM, otherwise don't. This
> obviously requires work on the individual apps themselves to define what
> they depend on, but also perhaps some common library code in KCM to make
> this easy, and libraries like KWallet need to define on what platforms
> their KCM is required. It was this work that we never got around to doing
> and that needs better defining if we're ever to get serious about
> cross-platform support.

That sounds like a considerable amount of effort which is going to require a good-faith attitude from all application developers. Automatising the process of exposing KCMs is going to be tricky because so many are not shipped with the framework they control.

And frankly, I like to have access to all global settings via a central utility that makes it easy to switch back and forth between several control panels. I think every user who likes to tweak things (i.e. those for whom we'd be doing this) is used to that kind of interface (because that's what's used on just about every platform nowadays).
More often than not, I find myself using systemsettings to tweak something rather than for instance activating kwalletmanager in order to get to the wallet settings through its menu. 

We'll see how consensus has evolved since that "Akademy a few years back", but I'd be very much in favour of simply adding a button or panel or whatever to the main settings template dialog used by all applications. Something that doesn't get in the way but is also not too easy to miss, and that gives access to shared/global settings. From what I understand, systemsettings uses an IconView class that should be accessible from any application to build the familiar interface to the available KCMs in any dialog window. If it's possible to combine that with some automatic selection mechanism of KCMs that are relevant to the current application ... fine, at least that'd not be reinventing the wheel completely, and we'd still be using a familiar interface that has earned its marks. I've grown weary of new-fangled interfaces that sprout from masters' theses and comparable efforts; they usually need significant time to become mature.
But let me just repeat that I'm not a big fan of having to launch separate applications to get at unrelated settings. Ultimately that's already possible with kcmshell5; all that's needed to streamline it is to provide individual wrappers that can be launched from an Explorer/Finder like GUI. And guess what, that'd look curiously similar to systemsettings/System Preferences/Control Panel ...

R.