KCrash

[David Faure]

KCrash automatically initializes itself with the use of 
Q_COREAPP_STARTUP_FUNCTION, provided that apps link to that lib.

This works OK, except for one thing: it gives no chance for KCrash to add 
--nocrashhandler to QCommandLineParser (in the case where the app uses that).

Which makes me reconsider the idea of automatic initialization, and rather
adding something explicit like
 KCrash::initialize(&parser);
.... in all apps, when porting away from KApplication.
And moving all of the startup function code into that.
Otherwise, we run the risk of apps magically using KCrash without knowing it,
not defining the option in QCommandLineParser, leading to
"no such option --nocrashhandler" (and an immediate abort) when kcrash 
restarts the crashed app with that option.


Ah!
There is one alternative....

Getting rid of --nocrashhandler altogether and using an environment variable 
instead. KDE_DEBUG=1 is the existing name for this env var, in the kde4/kf5 
code. I don't like it very much though, since it's not very descriptive.
So how about
- adding support for another env var in kcrash.cpp, say KCRASH_DISABLE=1?
- changing kcrash.cpp to set that var in startProcess()
(a bit tricky, this can involve kdeinit, but iirc it supports setting env 
vars...)

(Even KCRASH_DISABLE isn't very descriptive technically; we don't disable the 
fact that a crash handler gets called, but the launching of drkonqi from 
there. But from a user point of view I guess that's all that matters).

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5