improving debugging experience ;)
trapni at gentoo.org
Fri Dec 9 10:37:02 UTC 2005
On Friday 09 December 2005 00:46, Andreas Pakulat wrote:
> On 08.12.05 22:58:42, Christian Parpart wrote:
> > While in debugging mode, you're able to hover a symbol and get it's
> > data dump, just like an item in the "Variables View", however,
> > it is comprehensivily splitted up into a tree-alike popup stacked down
> > to just where your hover the next symbol within this popup.
> > While this is quite handy, there still is another thing I'm missing.
> Do you mean that this is in kdevelop already? Didn't see it yet, but
> maybe just missed it :-)
yup, you mixed it up. too bad :-P
VS.NET 2005 really has this feature, and once you get in touch with it, it's
really very much addictive.
do you need screenshots?
> > So now my idea is that KDevelop would just examine the data structure of
> > a variable. If it hits a certain base class FOO containing a certain
> > function BAR, then this one gets invoked and its return value is used for
> > the pretty display.
> > FOO and BAR shall be (of course) configurable, only one BAR per FOO and
> > multiple type of FOOs.
> I'm not a debugger expert, but I think this is already done today and
> you can do it yourself. For example for QString you get the string value
> in the variable view if you include the gdb-macros from the kdesdk
> package. I think the same is true for other Qt3 containers, like QMap
> and QList, even though I'm currently not sure how they appear in the
> variable view.
> If you look at those macros you can see that there's no "magic"
> happening, just some "interpretation" of the data in the "d" pointers of
> the classes (like QString, QMap and so on).
> > Is this even possible from a kdevelop/gdb technical point of view?
> The question is: Who is skilled enough with gdb to write this for each
> and every framework?
make it configurable by GDB in form of a listbox containing base class names.
each of them can be configured to contain a method to be invoked on display.
Think of a list like this:
* [SWL] TObject -> toString().c_str()
* [STL] std::string -> c_str()
* [Qt3] QObject -> toString().however()
* [boost] boostBaseClass -> theirRespectiveToCString()
you get the idea on where I'd like to point you?
this way even a dump framework dev/user could configure this up whilst STL and
Qt should be already preconfigured in this diealog (to be initialized on
first kdevelop invocation).
besides!: you are skilleed enough to hack a little bit on kdevelop then?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the KDevelop-devel