Version: (using KDE KDE 3.2.1) Installed from: Debian testing/unstable Packages It'd be neat if you could doubleclick on a line in the application output and then the line was scanned for a filename and linenumber and the editor brought to that location. Like when you click a line in the "grep" output. It'd then be easy to add kdDebug lines like kdDebug(24000) << k_lineinfo << "xxx" << endl; and while 'backtracing' the debug output you could simple click your way back and forth.
Not a bad idea at all. I'll take a look at this.
Related to #60671, #72076 and/or - http://lists.kde.org/?l=kdevelop-devel&m=108092404007307&w=2 - http://lists.kde.org/?l=kdevelop-devel&m=108094197531718&w=2 - http://lists.kde.org/?l=kdevelop-devel&m=108101428528071&w=2 ?
Yes, you're right, Daniel. This is clearly related. Even overlapping to some extent. I haven't looked yet at how easy this part would be to implement, but if it's as relatively simple as I think, I'll try to do it for 3.1. Alexanders plans about using konsolepart is probably a too large change to happen for the next release. I also don't think simply embedding konsolepart will work. Maybe we can fork it.. ;)
Heh. After having a look I realize this is already implemented. Asserts and k_lineinfo are already supported. In my brief tests, this worked perfectly. Linus, what are you missing?
I updated my CVS tree, recompiled and installed (version showing 3.0.90-CVS). I have kdDebug lines like: kdDebug(24000) << k_lineinfo << ", command: " << command << ", data " << data << endl; In the application output of kdevelop, I get: Quanta: [/home/..etc/file.cpp:518], command: wait,data as expected, but no matter how much I double click it wont jump the the right file/line. (It wont jump at all, to be precise) Could it be that I'm not running KDE from CVS? If it works for you, I guess it's implemented and its something wrong with my system rather than kdevelop. /LInus
Well.. the fact that it doesn't appear to produce a full path is clearly the problem. There is a regexp to retrieve the path from a k_lineinfo formatted output, but there is no logic to guess the path when it's not complete.
It does produce a full path, I just shortened it since I couldnt copy it from the output window. (Never pays off to be lazy, I suppose)
I guess if it doesn't work (and there will always be cases when it can't) then it's a bug, and if it's a bug it's a dupe... *** This bug has been marked as a duplicate of 123886 ***