[Qt-creator] Easy Description on how the "Pretty Printers" work in QtCreator

[André Pönitz]

On Friday 09 April 2010 17:32:11 ext Michael Jackson wrote:
> I am interested in porting some functionality from the QtCreator Debugger
> into another environment, specifically the ability of QtCreator's debugger
> front end to display a reasonable value for things like QString and such. 
> I understand that the first thing is that my code needs to link against the
> qtc-debugging-helper library.

Not really. This is only a fallback. Outdated to a certain degree even as
we try to us Python recently (which is no option on the Mac, though).

Usually the library is loaded into the process using dlopen or LoadLibraryA
or preloaded.

> I took a look at some of that code and it seems straight forward enough. 

Yes, the main idea is to make the dumper code as simple as possible as
this is what the user would have to create if he's to use a customized
version for his data types, and put the nastier parts into Creator itself.

> I even started digging into QtCreators gdb
> front end code (plugins/debugger/gdbengine.cpp) to try and figure out
> exactly what is going on but no such luck. I am a completely 'wet behind the
> ears' when it comes to directly interfacing with gdb. I have used gdb on a
> command line a few times in the past but not enough so that I am any sort of
> guru or even really know what is going on.
>   I guess what I am looking for is a basic sequence of events that describes
> how to get the "value" from the actual debugger into the Gui. So when the
> user looks down at the "local variables" area and sees a QString variable
> and it has "Hello World" as its value, how did "Hello World" end up there.

I do not to really want to discourage you, but let me point out a few 
cornerstones of such a "porting" project:

The main problem you are facing here is not getting data from A to B but
(a) the moving target "gdb" and (b) the moving target "Qt". (a) is not so
much a problem on the Mac as the releases are infrequent and without
much (visible) chance. (b) has bitten me around five or six times in the 
Qt 4.7 development cycle alone as some of the dumpers depend pretty
heavily on internal structures that are not part of the public interface and
change without notice. As a result of this, the dumpers have to be 
recompiled per Qt installation on the users system (or, as the fallback,
included for compilation in the user project, using appropriate copies
of the private structures). 

While the output of the dumpers follow roughly GDB/MI style structure, it 
omits for performance reasons various fields that a general purpose MI 
parser might need for its operation. On the other side, additional fields
are added, some of them containing even data that's expected to be
passed back in later invocations (see the QObject and QAbstractItemModel
related parts for starters). Porting that to Eclipse (that's the enviroment
we are talking about, right?) is certainly possible,  but it's a bit more effort
than, say, rewriting 3kLOC of dumper code. 

Just getting a QString or QStringList displayed is of course easy, but
for that you would not need Qt Creator's dumpers at all.

Andre'