Re: Python API - nested pretty printers MI implications

["André Pönitz" <andre.poenitz@nokia.com>]

On Monday 15 August 2011 16:48:55 ext Pedro Alves wrote:
> > [...]
> > Just to confirm I understood correctly: Assuming everything would work as 
> > planned, a good strategy for frontends is to call '-var-update ... *'. Then
> > gdb would walk the whole varobj hierarchy, running pretty printers as 
> > appropriate, and produce a "diff" against the last reported state which is
> > output as a changelist, announcing potential new children to the FE, 
> > which in turn could ask for that in another roundtrip.
> 
> Yes.  I believe things could be extended to avoid extra roundtrips.
> 
> > If so, isn't this very similar to the "fat script" approach, where a python 
> > command (fed with a list of "names" of the expanded items) does all
> > the tree walking by itself? That would put everything into "user space",
> > let the pretty printers output additional data that's not of "general"
> > (i.e. for all FEs) interest, and would make implementation of pretty 
> > printers with multiple phony levels straightforward?
> 
> Probably.  But doesn't that mean library writters would get to write
> pretty printers for each FE out there?

If the library writer wants to "support" every fancy feature of every FE,
then, perhaps, yes.

However, without that flexibility we are in "one size fits all" mode, where
gdb hardcodes which kind of data is deemed useful for every FE, and the
FE has to jump through hoops (like extra roundtrips to retrieve "missing"
 information, or ignore unneeded data) to get hold of what it (the FE) 
actually wants to display. [That's not just anticipation, I had that kind
of situations in the past when a varobj based "full display" of a QObject
based class resulted in 50 or more roundtrips, basically rendering the
whole approach non-viable]

Anyway, in practice I would expect most implementors of "library pretty 
printers" to just provide the "usual" data (i.e. most likely what the current
varobjs display looks like), and the FE to override a handful of them with
an FE-specific "enriched" version - if at all. A schism on an individual 
pretty printer level is certainly much easier to handle (especially if the
maintainance burden for "fancy stuff" is solely on the individual FE side)
than a schism on the fundamental "varobj vs fat script" level.

Andre'