<html><head></head><body>Don't forget security and privacy. The last n keys would be a bad thing to have if the user just entered a password.<br>
-- <br>
Sent from my Android phone with K-9 Mail. Please excuse my brevity.<br><br><div class="gmail_quote">Thomas Zander <zander@kde.org> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre style="white-space: pre-wrap; word-wrap:break-word; font-family: sans-serif">Quoting Niko Sams <niko.sams@gmail.com>:<br /><br />> On Mon, Mar 12, 2012 at 11:36, Thomas Zander <zander@kde.org> wrote:<br />>> I'd say this is a great idea, mostly because it means a lot more can be<br />>> automated on lots of ends.<br />>> Naturally, the actual automation means research and development, which means<br />>> manpower. I didn't get from your email if you wanted to volunteer for some<br />>> of this work :)<br />>><br />>> Personally I'd go for a solution that also tries to register the last 20<br />>> keystrokes and 20 mouse clicks (qt global event listener) and if and when a<br />>> crash occurs that info can be send with the backtrace. So even if there are<br />>> no debug packages installed we get some info to do data-mining on.<br />><br />> That would provide useful information? I guess
it
depends on the<br />> application and bug.<br /><br />In my experience its useful in many cases. If your application is <br />complicated then just having a backtrace, even with linenumbers, may <br />not allow you to reproduce the crash. You need some extra info to know <br />what the user did just before it crashed.<br />Asking the user is not the best solution; I've seen many backtraces <br />with a comment from the user stating they were typing some text, while <br />the backtrace showed they were printing. Its hard to be a debugger <br />when your work just got lost...<br />A better solution would be that we know which buttons were clicked and <br />that the user pressed the tab button or the ctrl-w buttons etc.<br />So, I'd say this can be very useful to get the whole picture of the <br />moment the crash happened :)<br /><br />And this also means that duplicates are good, the backtrace may be the <br />same but we still add useful info to the issue.<br /><
br
/>>> Either case, I'd think you want something custom written. Its not too much<br />>> work to do the basics and maybe we can steal some code that compares<br />>> backtraces and steal some ideas or code for on-disk data-store of those<br />>> backtraces.<br />> +1<br />> The existing solutions are very complex and have lots of features. And<br />> they solve different<br />> use cases.<br /><br />Hmm, its indeed not easy to find something fitting. Looking at the <br />code of one of the links found in this thread, I notice its written in <br />perl. While I understand the urge to do that, I'm not convinced that <br />there is enough perl knowledge in KDE to make sysadmin happy if we <br />just imported their systems. How hard can it be to parse a backtrace <br />anyway? ;-)<br />Anyway, the actual core parsing and matching will probably be <br />something that can be improved over time. Possibly with the help of <br />other open so
urce
code.<br /><br />-- <br />Thomas Zander<br /></pre></blockquote></div></body></html>