RFC: Disable DrKonqi
Martin Klapetek
martin.klapetek at gmail.com
Mon Nov 16 15:39:57 UTC 2015
On Mon, Nov 16, 2015 at 5:50 AM, Sebastian Kügler <sebas at kde.org> wrote:
>
> Perhaps only enable drkonqi for debug builds? That's the kind of backtrace
> that should be useful, otherwise the bt would be useless anyway...
>
> I'm not so sure about all this, I do think that backtraces are valuable to
> us,
> and I also think that it would be cheating to just hide the drkonqi window,
> but on the other hand, if it improves the user experience, that's good, no?
>
Plasma backtraces are unfortunately not always that valuable,
here's a list of some recent backtraces with 0 value for us.
https://bugs.kde.org/show_bug.cgi?id=355431
https://bugs.kde.org/show_bug.cgi?id=355427
https://bugs.kde.org/show_bug.cgi?id=354604
https://bugs.kde.org/show_bug.cgi?id=355302
https://bugs.kde.org/show_bug.cgi?id=354267
...and there is a whooooole lot more. And very often if you ask
"can you reproduce this?" the answer will be "not really, it just
happened".
Perhaps we could try and detect some of our stuff in the crashing
thread and only then offer sending a backtrace, like something
non-qt being present (ie. symbols not coming from qt libs). That
could get those really valuable backtraces to us cause obviously
not all of them are useless. So just expanding the logic that is
rating the backtraces (that thing behind the stars in drkonqi).
As for the general idea of not showing Dr. Konqi for Plasma
crashes, +1. A simple KSNI would do. This would have a timeout
for let's say a minute so if you don't act on it, it would just go
away.
Cheers
--
Martin Klapetek | KDE Developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20151116/d0efc1f0/attachment.html>
More information about the Plasma-devel
mailing list