<div dir="ltr"><div dir="ltr">On Sat, Aug 10, 2024 at 3:54 AM Joshua Goins <<a href="mailto:josh@redstrate.com">josh@redstrate.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thursday, August 8, 2024 9:06:03 AM EDT Nicolas Fella wrote:<br>
> Hi,<br>
> <br>
> TL;DR: Call KCrash::initialize() after setting up KAboutData<br>
> <br>
> crash reporting via DrKonqi to Bugzilla and Sentry is powered by the<br>
> KCrash framework, which acts as the crash handler inside the application.<br>
> <br>
> To install the crash handler you need to call KCrash::initialize() in<br>
> your application's main function. Since the crash handler relies on<br>
> information from KAboutData you should do it after the call to<br>
> KAboutData::setApplicationData(). For best results make sure to include<br>
> the application version in the about data.<br>
<br>
Thanks for posting this to the ML Nico. I'm wondering since 24.08 is close to <br>
releasing I want to get KCrash in for some of my applications. We're past <br>
dependency freeze, though. Assuming I do the usual way of using KCrash (adding <br>
to .kde-ci.yml and using __has_include("KCrash")) would that need approval <br>
from the release team to make an exception? Or is it so inconsequential it <br>
should be OK?<br></blockquote><div><br></div><div>My view would be that you're already depending on one or more KDE Frameworks, so using another isn't an issue.</div><div>This is essentially the same as using additional API from within a library that you already depend on.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Thanks,<br>
Josh<br>
<br>
<br></blockquote><div><br></div><div>Cheers,</div><div>Ben </div></div></div>