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