Resize grips were introduced for GNOME 3.0, before we had any of the
"new GNOME app" features like invisible borders and CSD. With OS X 10.6
and 10.7, Apple has replaced the classic grips in their applications
with invisible borders as well.
New GNOME app designs don't use resize grips anymore and the new
default theme for GTK+, Adwaita, disables them entirely by forcing their
width and height to 0.
They're past their time. Remove the code to support them. This can
always be reverted if some app relies on them.
That test is not working anymore by design since commit 57c4f01e.
It was introduced pre-3.0.0 in commit 12d6b588 and the feature was never
utilized. So it seems safe to just remove the test.
TextView border windows are internal windows used to draw on the gutter
of the textview (e.g. line numbers). The test uses the gmodule hook to
programmatically draw on the border-windows at each side of the textview
and compares the result with 3x3 grid of labels.
add a reftest that checks GtkTextView text margin property comparing
with the normal margin added to the widget (they are the same when there
is nothing drawn in the gutter like line numbers etc).
This tests just a few basic things for now. Mainly, that we don't
emit redundant notifications for enum, flags, int and boolean
properties. It also checks that we do emit the expected notifications
when the value actually changes. This is checked for string, double
and float properties as well.
There is a large number of exceptions in the test, and a lot more
checks that could be done. One class of exceptions is all the places
where we have -set booleans to go along with another property. We
should have a dedicated test for these pairs. Another class of
exceptions is where naked objects created by g_object_new () just
don't have the full functionality - e.g. a tree selection without
a tree view does not work very well. We set up the instance object
better for these situations.
The reftest is testing "transparent" works as expected by drawing a
purple background once with purple and once with transparent and
expecting the same result. This works fine unless anti-aliasing happens
at rounded corners. The overdraw of the 2nd background changes the
antialiased pixels.
Fix this by explicitly setting the border radius to 0.
Also reindent the file to make it more readable.
This tests both a sequence being claimed early to be then denied
(and handled deeper in propagation chain), and a sequence being
claimed late in the capture phase (and thus being cancelled deeper
in the propagation chain)
