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

[Ian Wadham]

Hi René,

On 21/12/2015, at 10:05 PM, René J.V. Bertin wrote:
> This has been pending for a while, ever since we (= KDE/Mac) learned that the kde4-workspace package was split up and integrated into KF5 Plasma, but it may actually be relevant beyond "Plasma vs. the rest of the world" questions.
> 
> I hope this can be discussed with a sufficient amount of open-mindedness and flexibility.
> 
> The KDE Workspace API docs page (http://api.kde.org/4.9-api/kde-workspace-apidocs/index.html) kicks off with a rather clear statement that seems a little, excusez le mot, short sighted:
> 
> "This is where the components that are only used when KDE is providing a complete desktop environment live."
> 
> I do not want to contest that there are indeed such components in there. But there are also components that *do* make sense outside of a full Plasma session, components that were the initial and main reason we provide a kde4-workspace port for OS X.
> 
> At least part of the utilities provided by kde-cli-tools and an application like systemsettings are definitely useful even when not running a full Plasma session, as they are required to configure components that are independent of the session type. Someone could want to use KMail under a Unity, Gnome or KDE4 session, or use Konqueror5 ... and the same could be said for OS X or MS Windows users. In fact, one of my main motives to bother with KDE and KF5 at all is the fact that I use Kontact (KMail, KNode etc), and hope that one day in a near future I will be able to upgrade from the KDE4 version I am using at the moment. On OS X and on Linux systems which I may to keep to a KDE4 desktop otherwise.
> 
> 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)
> 2 cookies and other html/browser related settings
> 3 akonadi/PIM settings
> 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.
> 
> There may be others; those are just the ones that come to mind first because they're the ones I use most with KDE4.
> I realise that 4-6 are dependent on whether or not one accepts the fact that a KDE application might want to control its appearance beyond what Qt's native/stock implementation provides (has foreseen) on the platform. This discussion has been held elsewhere already, and I think we've come to some sort of agreement that it's not "evil" to allow users to fine-tune fonts, colours or use a different style (Qt allows that anyway) or even platform theme. 
> Systemsettings might be called something else on non-Plasma platforms, but that's a bit of a different topic.
> 
> There may also be other Plasma/Workspace components that are concerned ... for instance the Breeze or Oxygen themes (as far as they can still be built without X11 since the introduction of KDecorations).
> 
> So ... I have begun packaging systemsettings and kde-cli-tools and have draft implementations that build and work on OS X and Linux (= KF5 installed in /opt/local under a KDE4 desktop). At this point I'm very open to suggestions on which of their components I might want to deactivate from the onset, like the kcm for KActivities. (KActivities is actually something I'm doubtful about myself, but that may be because I've never seen its use on my KDE4 desktops either.)
> I'm surprised that I don't see any of the fonts/palettes/style controls; those are probably in a separate package?
> I'm also surprised that I see some KAuth headers being included, but that no KAuth dependency is declared, and that (as a result?) the kwallet KCM doesn't allow modification. This gives me a vague sense of deja-vu, but I think the issue we had here with KDE4 was that KAuth needed fixing for OS X back then. As far as I can see that fix was incorporated into KF5 KAuth, so what am I missing here? I get the same in my Linux build, btw.
> 
> Sorry for another long email; this just cannot be addressed by talking in bullet points.

No, this is a good initiative. René, and a necessary one.  Such complex
considerations cannot be dealt with easily in a short exchange of emails, IMHO.

Sebastian Kügler wrote on this thread, in reply to you:
    "A general assumption is that stuff in kde/workspace either isn't suitable or 
     really useful on OS X, or that it should move elsewhere (at that point, it may 
     make sense to put it into or make it a Framework). You name a few candidates."

I am not subscribed to plasma-devel, so I doubt if what I have to say will reach
Sebastian, except via you.

One glaring "candidate" that got swept into plasma-workspace as a matter of
convenience (though it used to be in kde-runtime), is KDE's crash-analyser "app",
Dr Konqi, which is invoked by default from the KCrash class in every KDE app.

I think this move happened in about February-March 2015.  The discussion was
probably on plasma-devel, which may explain why I am unable to find the thread.

Here is a thread I started in September on kde-core-devel, though it did not get very far.

    Location of Dr Konqi in Frameworks/KF 5
    http://marc.info/?l=kde-core-devel&m=141016489232297&w=2

Marko was also protesting about the move, I remember.  I think the earlier thread,
where the powers the be decided to move DrK, had the same subject line, if you
would like to try and find it.

The problem with DrK is that it is a big, complicated comment-free chunk of code
that drags in everything but the kitchen sink (even some stuff from KDE PIM libs), in
the usual (dis)integrated KDE 4 style.  It has far too many and too large dependencies
to be tucked away as a supporting app in Frameworks, which is where it really belongs.

Aleix Pol listed 13 of the dependencies at the end of the above thread.

The question is whether KDE developers wish to receive crash reports from OS X,
Windows, etc. in the format they like or would be content with Apple or Microsoft
formats.  That is if they are ready and willing to respond to crash reports from
non-Plasma platforms anyway...

The real problem is that there is nobody around any more who has worked on
DrK code recently (except me, I suppose, and I have had a gutful of it, frankly).
So nobody is likely to "clean it up" and reduce the dependencies.

Cheers, Ian W.