[KDE/Mac] Review Request 120431: Fix and future-proof Dr Konqi security methods on Bugzilla

[Ian Wadham]

Hi Hrvoje,

On 30/10/2014, at 6:54 AM, šumski wrote:
> On Wednesday 29 of October 2014 00:16:13 Marko Käning wrote:
>> On 29 Oct 2014, at 00:05 , Hrvoje Senjan <hrvoje.senjan at gmail.com> wrote:
>>> forward port, for interested ones ->
>>> https://git.reviewboard.kde.org/r/120876/

See my comments in that review. Also see
http://mail.kde.org/pipermail/kde-frameworks-devel/2014-October/019922.html
for some further thoughts on Dr Konqi, arising from the amount of time I have
spent going through the code and trying to understand it.

>> Wow, does this mean, that DrKonqi has now been ported to KF5?
>> 
> Correct, it was building since early days, but only 'recently' it got ability 
> to actually report bugs. But due to bug Ian was addressing in his review, it 
> is ATM kaputt. Thus my attempt to forward-port that fix ;-)
> 
>> Well, still, on OSX it’s pretty useless to have DrKonqi in
>> plasma-workspace, as this is a framework which doesn’t get installed there
>> (due to its dependency on X11)…
> Idea was to get it into KCrash framework, but due to various dependencies this 
> didn't materialize yet..

It is great to see someone working on Dr Konqi for KF5, Hrvoje.

I really do not think you will reach the goal of removing enough dependencies to
make Dr K qualify as a "framework".  There are loads of dependencies, both direct
and indirect.  I think your best hope might be to get KCrash to invoke a very simple,
stripped down version of Dr K --- if possible without ever forking.  Let's call it K1.

K1 need not be a GUI process.  It could simply capture the backtrace data
and the command-line parameters of the present Dr Konqi and save them
somewhere, such as on a Qt 5 temp file.  Then K1 could launch a K2 (GUI) app
that goes through all the rest of the stuff Dr Konqi does.  This kind of split would
also enhance the chances of K1 functioning no matter what kind of crash occurs,
leaving K2 to pick up the pieces in a quieter environment.

K1 should be able to reside with KCrash.  K2 would have to reside with some KF5
analogue of KDE 4's kde-runtime (i.e. bits and pieces that are needed by typical
KDE apps at runtime).  Clearly, K2 could not reside in plasma-workspace, unless
you are prepared to provide other versions of K2 for Apple and Windows… :-)

OTOH, you could consider some other (multi-platform) kind of crash reporting, see:
    http://en.wikipedia.org/wiki/Crash_reporter
    https://wiki.mozilla.org/Breakpad

All the best, Ian W.