Re: padding cleanup

[Havoc Pennington <hp pobox com>]

Something that occurred to me mid-bisect is that with Benjamin's
draw() work, it would probably be straightforward to write the
following test program:

* instantiate every widget type in GTK (or even various modes of every
widget type, like different text styles, wrap or not, padding/border
or not, etc.)
* dump a giant directory of PNGs representing the paint of every one
of those in every GtkStateType

This is already useful because it can be manually inspected and used
for example to verify that a theme engine works.

But then a natural extension is that you could write a "PNG cmp" tool
(load two PNG, compare pixels). Then dump widget renders before, dump
widget renders after, compare.

If you could control for environmental issues (fonts, font settings)
you could have an automated test that 1) ensured the allocate/draw
codepath didn't crash or spew debug spam for any widget in GTK (use
G_DEBUG=fatal_warnings), and 2) got upset if anything changed about
how widgets are rendered. If you changed rendering on purpose, you'd
just regen the canonical images.

You could even easily test layout algorithms (just render various box
packings). And automate testing of widget properties by having handy
routines that set every possible enum value of a prop, for example,
rendering them all.

Seems like a really simple way to get _huge_ test coverage. I guess it
was possible already by starting an Xvfb (which you'd have to do
anyhow) and taking screenshots... but that might have been slow and/or
racy, I don't know.

Well, a project for a rainy day. It would have caught this little buglet ;-)

Havoc