drkonqi adjustments - Better Crash Handler for KDE 4 ?

[Adrien Guillon]

Hi,

There are two things I'd like to propose... first is improvement to Dr. Konqi, 
second is perhaps a motivation for a better overall "crash framework" for KDE 
4.  I'm a bit of a newbie developer with KDE, so any advice and direction 
would be appreciated :-)

We use KDE corporately for some 60 users... we do experience crashes from time 
to time, and our support team needs to know what is happening... and we don't 
want users to directly report to the KDE project... since users may paste 
confidential information, report problems that are really training issues, or 
report problems that have nothing to do with KDE.

To allow us to do this, I think the best solution would be for us to be able 
to override the --bugaddress argument od drkonqi with something coded in the 
KDE Configuration framework.  This way we can add the bug report address in 
the rc file.  We can filter through bug reports ourselves, forwarding 
legitimate ones to the KDE project, removing confidential information if need 
be, and generally manage our problems ourselves.

For organizations with their own support team, I think this is the best way to 
manage things.  But thinking on this issue made me ponder more options to Dr. 
Konqi... and I thought that perhaps KDE would benefit from a larger-scale 
crash framework.  Additional options that would be nice for Dr. Konqi:

1)  An option send to the KDE bug list, and BCC to another address (perhaps 
our internal bug tracking system).

2)  An option to override the bugaddress command line argument, and force 
sending to a specified address regardless of how drkonqi is called (useful 
for sysadmins and support teams to know what is happening). (I can patch this 
one myself, reading a configuration entry from the rc file)

3)  Perhaps we can have a 'hook' that will allow us to escape to a shell 
script or other application so that we can format the resultant bug report as 
we wish... we might want to include some information from the users' home 
directory, or other debugging output.

I don't know if such a thing exists, but a larger crash framework would be 
nice for KDE 4... something where we can intelligently specify actions to 
take... and use to escape to scripts for handling ... for example "if  kontact 
crashes, then set debugging output for the next run of kontact"... this way 
we can intelligently debug the problems.  Always outputting debugging output 
is too much information, and it's only useful if we can repeat the issue 
anyways.  I would imagine that it would be useful for developers too... if 
someone is reporting frequent crashes on the buglist they could be given a 
script that would give the developers more information at crash-time...

I realize fully, that over-complicating a crash framework can lead to 
something that is very very unstable... but I suggest something that is 
extensible that allows us to escape the crash logic to a separate 
application / script / class... and is only able to be set by sysadmin-types. 
This way an organization can figure out how to handle crashes themselves... 
think of it as a try ... catch but on a corporate level... at the very least 
I'd like to know as an administrator when crashes happen, and who for...

What do you think of the basic idea of a more sophisticated crash handler for 
KDE 4?

Thanks!

AJ