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, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
