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

René J. V. Bertin rjvbertin at gmail.com
Mon Dec 21 13:22:41 UTC 2015


Aleix Pol wrote:

>> kde-cli-tools and systemsettings5 are required to configure
>> 1 wallet settings (regardless of whether KWallet uses native KDE wallets or
>> an OS X keychain backend)
> Makes sense, probably should be moved to KWallet?

Probably.

>> 2 cookies and other html/browser related settings
> What does it configure? is it only for KHtml?

You can probably check better than I can at the moment, for the KF5 version at 
least :) On KDE4 it configure what cookies to accept, allows you to edit the 
cookie jar, to chose the html engine and probably a bunch of other things that 
are evidently related to HTML and Web functionality in KDE code.

> 
>> 3 akonadi/PIM settings
> It should probably go to PIM.

Yes.

As a general rule I think one can say that every application that uses a KCM 
module to configure part of its settings should provide a means to edit them.

But wait, that already exists ... kcmshell :)

Would it make sense to move kcmshell to a framework, replacing its payload with 
a kpart? Or is there some fundamental reason why kcm modules cannot run in the 
address space of an application other than kcmshell or systemsettings.

> 
>> 4 fonts, icons and palette settings
>> 5 style settings
>> 6 interface settings like "click once or twice to open", "show icons in
>> buttons/menus" etc.
> 
> Here, it should integrate with the OS, IMHO. Like Plasma, OS X should
> have a place where to configure those.

If we forget about running (and configuring) KF5 applications under a non-Plasma 
X11 environment, then you have a point.
However,

> I don't think it's fair of us to ask the users on OS X to know the
> application is special and that they need to go to a special place to
> configure some details of how the application is going to behave.

Fair enough. But you can also not ask of the OS to know about a family of 
applications which have an additional set of configuration settings, many of 
which are not configurable on a system level in OS X. Careful, I'm not claiming 
it's unheard of to configure specific details of an application's user interface, 
but that would be application-specific. Either the application would provide the 
interface to configure those settings, or it would provide a "PreferencePane" 
(the equivalent of a KCM), for instance if the application is part of a family.

The easiest way to achieve this would be to provide a PreferencePane that adds 
an entry to the OS X "System Preferences"; there exist several of those which 
simply launch an external configuration utility instead of loading something like 
a KCM. Loading KF5's systemsettings that way would mean we don't have to write a 
whole comparable interface from scratch while users can still access it through 
the familiar interface (sounds like a win-win to me).
BTW: PreferencePanes can be installed at the system level or per-user, and 
installation is triggered simply by double-clicking on them, so no sweat there.

Alternatively it might be possible to that the approach describe above, and use 
a framework and kpart to load kcms in an application's address space. That way, 
interface settings could be made accessible through the Settings menu just like 
Notifications and Shortcuts are currently.

> Regarding kio-cli-tools, these should be cross-platform and were never
> meant to be part of plasma. It probably would even make sense to move
> it to KDE Applications now?

You tell me :)

I do understand that I can thus expect patches for kde-cli-tools to be welcomed 
(for instance to avoid app bundle builds). Good.

R.



More information about the Plasma-devel mailing list