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