drkonqi adjustments - Better Crash Handler for KDE 4 ?

[Nicolas Goutte]

On Saturday 19 August 2006 14:16, Nicolas Goutte wrote:
> 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.)

I have mainly thought about setting it at compile time but perhaps some ways 
of forcing at run-time would be needed too in your case.

As for compile time, it would be surely useful for distriibutions, which could 
set a bug address of their own to support their users. 

This would also avoid problems with users thinking that reporting a bug to the 
bug wizard in the Help menu means reporting the bug to their distribution.
(I especially mean the bug report #89235: 
http://bugs.kde.org/show_bug.cgi?id=89235 
Sorry but the discussion/argument/fight/flame is in  French.)

Another variant would be people offering users to write bug reports in their 
own language, as many users do not know English (enough?).

>
> 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!
Have a nice day!