Re: No-op draw polygon with GTK_SHADOW_NONE?

[otaylor redhat com]

BJerrick easystreet com writes:

>     From the gtk_default_draw_polygon() code in gtkstyle.c, and
> from experiments, it would appear that drawing a polygon with
> GTK_SHADOW_NONE is a no-op.
> 
>     (The switch at the top of gtk_default_draw_polygon() has no
> case for GTK_SHADOW_NONE, so the default label is taken, which does
> an immediate return.)
> 
>     Can this be so?  Am I missing something?  It seems like a major
> omission.

This definitely intentional - compare, e.g., gtk_default_draw_shadow().

I'd say that the reason for this is that drawing nothing for a shadow
of none is definitely better than drawing the background color -
because you may have pixmap backgrounds; and while a solid colored
bevel on a pixmap background looks OK, if the background color
and pixmap are coordinated, a solid "nothing" on a pixmap background
does not look OK.

Also, this code really shouldn't be called with SHADOW_NONE at
all, I could make a case for:

 g_return_if_fail (shadow_type != GTK_SHADOW_NONE

SHADOW_NONE is really there for such calls as 
gtk_scrolled_window_set_shadow_type(), and most widgets that
take a shadow_type() of NONE will omit the space for the shadow
entirely in their drawing code.

So, it's hard for me to say what I would expect SHADOW_NONE to
do; doing nothing is perfectly reasonable and what we do 
now.

The basic thing to recognize here is that trying to "undraw" things is
a bad idea, and will get worse as we have antialiasing, alpha
blending, etc, in the future. If you need to redraw something, you
need to clear to the background, and do all the layers.  If that
flickers, use double buffering. (You have to work to avoid double
buffering in GTK+-2.0)

Regards,
                                        Owen