[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 13:11:44 Ian Wadham wrote:

Goodevening Ian, and whatever appropriate to ye'all :)

>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.

Thanks, Ian! I agree... :)

>> 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 one is actually simple: it seems that the authentication implementation was never finished: things are set up to expect it, but no "authAction" is ever installed... I filed a bug report on this via kwalletmanager's builtin report tool, but I have an impression sets the wrong product (given how few recent reports I found).
Maybe no one actually cares whether password storage works as it should (among users I mean)??!

>
>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.

Bouncing back to plasma-devel.

>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.

>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,

Yes, and I remember chiming in on one of our own discussions. I haven't made this a priority until now because what little I've seen of DrKonqi5 on Linux/Plasma5 is that it is much more prone to crashing that the software it's supposed to report on.

>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 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.

We'd have to see how much of that is still true in the KF5 version. The dependency list Aleix posted is large, and sadly missing all non-framework dependencies, but none of the ones listed are off-limits to non Linux/X11/Wayland.

It does make sense to leave it out of KCrash: it's a runtime dependency.

That said and re: KWindowSystem: I created a RR about an initial implementation (fix, rather) of the OS X backend; unless I missed something that ticket hasn't seen much activity.

> 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.

I have a little hunch that most KDE devs do not use DrKonqi themselves to file reports (but instead fix them directly, or maybe they're running everything from a debugger, what do I know :)). I'm just implying that those who know its code the most intimately may be the ones using it the least, and thus the most unlikely to notice functional issues with it.

R.