Pretty-printed MI vars with children get "{...}" instead of the wanted string

[Noam Yorav-Raphael]

Hello,

I sent this as a bug (
http://sourceware.org/bugzilla/show_bug.cgi?id=10616 ), but as this is
an intended behavior, Tom asked me to raise the subject on the mailing
list.

The current situation in the python branch is that if a pretty-printer
has both a to_string() method and a children() method, in MI the
to_string method is ignored and instead "{...}" is used. The result is
that in a GUI which uses gdb as a backend, a variable gets no
meaningful text near it; it looks like this:

[+] x   {...}
[+] y   {...}

Only if I open the "x" node, I see meaningful stuff:

[-] x    {...}
 |---a   1
 |---b   2
 |---c   3
 ... more fields
[+] y   {...}

I have structs with quite a few number of fields, but only a few
usually change during the running of the program and should be
constantly viewed. I wrote a pretty-printer for the struct which
returns the important fields in the to_string() method, so now the GUI
should look like this:

[+] x   a=1,b=2
[+] y   {...}

And of course I can open the "x" node if I'm interested in some other
fields. This saves a lot of screen space and lets the user focus on
the important stuff.

I also wrote a pretty-printer to display 64-bit machine words, which
are treated as a vector of 8 bytes. Thus I see in the GUI:

[+] x   1,2,3,4,5,6,7,8
[+] y   {...}

I might have to make the "locals" pane (which is located on the left
side of the screen) a bit wider, but since today's screens are quite
wide, it's not a problem.
If the to_string() method is ignored, I have to open the variable view
in order to see the bytes:

[+] x   {...}
 |---[0]   1
 |---[1]   2
 |---[2]   3
 ... 5 more lines
[+] y   {...}

Since I only have about 30 rows to view locals, using 9 of them just
to view the value of x is quite wasteful.

So, can this be changed? I'm sure there are reasons why the current
behavior was chosen, but as you see, using the to_string() method can
improve the debugging experience significantly in some situations.

Thanks,
Noam