On Mon, Nov 16, 2015 at 5:50 AM, Sebastian Kügler <se...@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
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
