[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Some thoughts and brainstorming about DrKonqui crash handler dialog
From:       Darío Andrés <andresbajotierra () gmail ! com>
Date:       2009-01-22 22:57:20
Message-ID: a2c126ef0901221457s4d22fd54yfa1bd6c547e99fc4 () mail ! gmail ! com
[Download RAW message or body]

DrKonqui crash handler dialog brainstorming:

- Include some information (tips) from:
http://aseigo.blogspot.com/2009/01/bugskdeorg.html

- Ask for inclusion of more information on the report
  Tell the user:
    "What were you doing when the application crashed ?"
    "Documents (or reference to documents, type, and so on) that you
were using when the app crashed ?" (explain how to attach small
documents (if the user can publish them))
    "Steps to reproduce the bug" (if the user knows how)
  [Already implemented in my test version]

- Autodetect KDE and QT versions, OS and Architecture/CPU
  Easy to do (some KDE/qt functions, and "uname" parsing (Windows have
it's own crash dialog, Mac should have uname, not sure about other
OS..)
  [Already implemented in my test version]

  Easy way to select all this info to paste in the fiels report
(during the wizard), and to paste the whole versions info (text block)
in the report

- Autodetect crashed app version ?
  Not sure if this is posible for 100%. Anyways it may not be relevant
as the most part of the KDE apps use the KDE distribution/version
scheme.

- Autoloading crash details (backtrace) with an option to "Cancel the
automatic load" or .. "Inmediatly display the backtrace"
  This may be controversial. But at least, from the users point of
view ("enduser" drkonqui profile), we always need the backtrace.
(later checking if it's valid) So you should encourage the user to
check the backtrace always.
  May be a prompt should appear warning about the CPU and hard disk
high load during the backtrace gathering process but encouraging the
user to do it to help the project reporting the crash
  [Partly implemented in my test version]

- Tell the user to copy&paste the backtrace into the report instead of
attaching it.

- Tell the user that if he finds a duplicate, the backtrace should be
very similar in order to post it in that report.

- Check if the user knows how to reproduce the bug (some prompt about
that) and enable the "Report Bug" button
  (or check user level experience . or something like that)

- Better detection of invalid backtraces (?) (detect
qt,Kdelibs,kdebase, and app related symbols?)
  Not sure if is there a way to do that
  - A way to detect asserts even in invalid backtraces (parsing output
?) , not sure if that is even possible at this pint

- Link to HowToCreateUsefulBacktraces techbase page... (when the
backtrace is invalid or always?)

- Detect distribution (not sure how to do that)
  This is already done in the Report Bug dialog (I think there's a
Kdelibs thing)
  - Provide Ubuntu(/AnotherEasyXDistribution) users more help :) (I
was told that there is a ubuntu wiki page for generating better
baccktraces...). Or ... an easy way to install the dbg packages...
(install kdelibs5-dbg , then reproduce the crash... or something like
that)

- Detect if the crash is related to graphics/hardware and ask the user
to include that details
  May be a component detection (kwin crash is more likely to be
hardware/graphicscard related crash than other kdebase applications
one), or may be looking for some hints into the backtrace (libGL?)

- Tell the user that we may ask for some information later so , if he
has to register a bugzilla account he should use a valid (and periodly
checked) mail address.

- The user should file different reports for different backtraces.

- If the user doesn't speak english (or he does it wrong like me :P)
encourage him to use a translator (google translator) and paste all
the non-technical details in english
---

As this is too much for the current dialog, we should
relayout/redesign it to include all the information and may be.. doing
it more non-experienced user friendly.

We need usability team help here.
--

There was an idea about implementing a Report Bug Wizard as a KDE App
(but it cause high load in the server), and it should include views
(to list and show duplicates) and everything the bugzilla wizard
already provide.


----


You can add , modify, remove, comment or suggest anything you want
Thanks in advice.
Darío
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]