Improving Dr Konqi for developers

[George Kiagiadakis]

Hello,

On Mon, Aug 9, 2010 at 2:17 PM, Milian Wolff <mail at milianw.de> wrote:
> Hello people!
>
> Since GSOC is nearing an end, and I hope to have a bit more time afterwards, I
> wonder whether it would be OK if I'd try to improve Dr Konqi a bit more for
> developers.
>
> For me, the tool is invaluable since I can run my application and crash it
> (yay :)) without rerunning it in GDB or doing some esoteric GDB core stuff
> manually. It's really a big time saver.
>
> I do miss some features though, and wonder what you all think of them:
>
> 1) "jump to crash" button or similar. Dr Konqi is nice enough to insert
> [KCrash handler] in the BT, but so far I have to navigate there manually. Why
> not make that faster?

That would be useful, I have thought about that as well.

> 2) "jump to thread" combobox or similar, see above, jumping to Thread X is
> sometimes also nice.

Maybe, but I don't find much value in this feature, plus that extra
buttons will clutter the UI even more.

> 3) open file, when hovering a URL I'd sometimes like to open that one quickly,
> just like e.g. Konsole offers me to.

Are there URLs in the backtrace?

> 4) syntax highlighting. Ok well, you guys know me from Kate/KDevelop, I'm a
> color whore and think it would make it easier to grasp a few things. I won't
> embed Katepart of course, but QSyntaxHighlighter should be enough for the
> simple GDB backtrace format.

That would be cool.

> Now, why do I write this stuff here, instead of just implementing it:
>
> - I don't know whether you would also find it useful as a developer
> - I'm not sure whether all this should be shown to John Doe who just wants to
> report a bug. Maybe it even increases the overwhelming effect of this dialog,
> and I don't want that. So ideas on how to make it optional maybe would be
> welcome (some non-UI setting maybe?)

That is an issue. In fact, Dario Andres who designed the interface
tried hard to make it clear for the simple user and I think we should
keep it that way. However, it would be possible to have such features
as optional, just like we currently have the "Debug" button (which
appears only if you set a specific key to 'true' in drkonqirc, see
drkonqi's README for details).

> - I know that Dr Konqi must be rock solid, and introducing new features might
> mean new bugs. So maybe instead of changing Dr Konqi I should put this into a
> different application (I'd then probably just write a KDevelop plugin for
> backtrace files).

I think keeping it in drkonqi is better. If drkonqi crashes now, it
should be able to catch its own crash and show a new drkonqi dialog
with a minimal set of functions available, so if you just make all
these new features unavailable in this case, it should be safe enough.

So, to conclude, +1 from me. And if you need any help with the code, contact me.

Regards,
George
--
Current DrKonqi maintainer.