drkonqi adjustments - Better Crash Handler for KDE 4 ?

Nicolas Goutte nicolasg at snafu.de
Sat Aug 19 13:16:01 BST 2006


On Friday 18 August 2006 18:54, Adrien Guillon wrote:
> 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:

Sorry, but I do not understand what it has to do with Dr. Konqui.

The class KAboutData has an bug email address. If this is not set by the 
program http://bugs.kde.org is assumed.

So I suppose that your mechanism should start in KAboutData. Perhaps 
http://bugs.kde.org should be the default and be really defined by the class 
(and not something that the repsective tool/program must know).

That would allow to override that address (including eventual email addresses 
for bugs), e.g. with a parameter at configure time or so. (Sorry, I do not 
know cmake yet.)

Then when some low-level mechanism would be defined, it could be implement in 
more higher levels, probably the crash handler and the bug report wizard in 
the Help menu.

(And, no, sorry, I am not a volunteer for implementing any of the above.)

>
(...)

Have a nice day!




More information about the kde-core-devel mailing list