plasma-desktop on other environments (bis)

[René J. V. Bertin]

Kai Uwe Broulik wrote:

FWIW, a good part of the KCMs you seem to think I include on OS X are in fact 
excluded because X11 isn't provided.

> The following are redundant with the system-provided ones:

> * componentchooser

As long as KDE code uses its own way (or a Qt-provided method, I don't know) to 
determine what application to use this will continue to make sense. 


> * translations

No, KDE translations aren't linked in any way to the way the system handles 
these, at least not on OS X. This is especially true for applications that 
cannot or shouldn't be provided as app bundles (anything ecm_mark_nongui).

> * fonts

No, KDE has its own set of font roles which are independent of the system, but 
which are used (expected) in KDE interface design. Without support for them, 
applications look just awful on OS X because most text elements will use what Qt 
considers the platform default font (Lucida Grande 13). The result is an 
appearance as if designed for the visually and motor impaired (large, spacey 
interface).

> The following could be used but should not:
> * Colors - KDE applications should just follow the system's colors
> * Style - KDE applications should just use the native theme provided by Qt

Again, don't agree in the sense that there shouldn't be an interdiction to do 
something else. It should be up to the user, and I'd even go so far as to say 
that this would be a big plus for KDE applications on OS X. It is near 
impossible to alter the interface of an application using pure Cocoa SDKs, but 
that doesn't mean individual users couldn't boost their productivity by tweaking 
the interface to their personal taste. OS X is a great OS but created by one of 
the biggest control freaks one can imagine; well-conceived user-configurability 
thus becomes a sales argument on it.
On OS X there's the additional reason that the Macintosh style is not very 
robust and often leads to misaligned and/or overlapping controls, esp. buttons 
and comboboxes. This is visible in parts of Kate, but becomes extreme in KCalc.

I agree that lookandfeel has little interest, but that's probably because I 
don't see its point anywhere. Disabling it will also make my patch simpler, I 
think.

> * Standard actions (that's for changing defaults like
> Ctrl+C) - KDE applications should just follow the system's shortcuts which
> Qt's QPA already takes care of

No, only for a very actions.

> The following are unneccessary because we don't provide/have to provide that
> feature outside a full Plasma session: * Autostart
> * Global shortcuts

Through kglobalacceld? That is part of a framework that's supposed to work on 
all major platforms, and as far as it has ever been functional there I don't see 
why it wouldn't be possible to configure it.

> * Activities

Ditto.

> * kded (perhaps we have a kded running, in this case: wtf)

??? Kded is required for certain features like cookie management. It may be 
overkill to provide a KCM to control the services it provides, but the same 
would be true everywhere.

> * Phonon (why does this thing even still exist)

Because it handles audio and hasn't been reintegrated into Qt? Without phonon, 
no sound, not for notifications, not in kdenlive (or video, for that matter).
At the moment there isn't much to configure but a future VLC and VLC backend 
should expose individual audio devices (rather than just the default device 
selected through the system preferences). That will make it possible to route 
notifications to one device, music through another and video through yet another, 
just like on Linux. There is no fine-grained control of that at the system level 
on OS X, it's left to applications. 

> The following I have no idea what they even do:
> * Krdb

It seems to be a component in a number of other KCMs.

> * icons - might be desirable for the user to change but then we could
> also enforce Breeze icons on other platforms as part of our design, especially

Oh please no, that would really look wrong on OS X.

>* spellchecking -
> but then Sonnet should follow / use the platform's settings and dictionary

We'll get back to that when it does, then.

Just remember that all these KCMs do is providing an interface to settings that 
exist and can be modified by hand if required. Settings that are problematic on a 
given platform, for whatever reason, should indeed better be disabled. Doing 
that with settings that work fine (like shortcuts) is just going to make the code 
more complicated.

I agree that the default configuration in a clean KF5 install should correspond 
to platform guidelines, but if the functionality exists to adapt those settings 
to personal preference or capabilities users should be able to benefit from it. 
It's an added value.

> As for non-KCMs, both OSX and Windows provide a native replacement for
> KNetattach.

I haven't yet figured out what that does. It built, so I didn't exclude it for 
now.

R