DrKonqi improvement idea

[henry miller]

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 <zander at kde.org> wrote:

Quoting Niko Sams <niko.sams at gmail.com>:

> On Mon, Mar 12, 2012 at 11:36, Thomas Zander <zander at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120313/43840043/attachment.htm>