Re: GtkTreeView breakage in master

[Kristian Rietveld <kris gtk org>]

On Sun, Dec 5, 2010 at 5:39 AM, Tristan Van Berkom
<tristanvb openismus com> wrote:
> It seems that the problem has something to do with the
> recent gdk changes, dirty areas in the treeview seem to
> miss out on getting redrawn (GdkWindow issues ?).
>
> Here is a screenshot of the problem:
>  http://people.gnome.org/~tvb/broken-testtreeedit.png
> Usually there are supposed to be 4 rows of data, the
> other rows disappear after resizing the window (oddly,
> it seems they disappear only once the GtkCellRendererProgress
> is shown)... mousing over the rows make the rows re-appear.

Interestingly, this is a bug in the drawing path of
GtkCellRendererProgress.  This only occurs if the bar_size
GtkCellRendererProgress is about to draw is zero.  In this case, there
is actually no rectangle to be drawn (width or height will be zero)
and gtk_render_background() will screw up.

I modified GtkCellRendererProgress in master to not call
gtk_paint_box() if bar_size is zero, simply because it does not make
sense to try a draw of a zero-width or zero-height rectangle.  This
fixes the issue seen in testtreeedit.

I guess it is useful if somebody checks gtk_render_background()
though, I do not think it is intentional that an attempt to draw a
zero-width or zero-height rectangle screws up all subsequent
rendering.

> Also, it seems the buttons in the treeview columns (and
> the rendered GtkCellRendererProgress) have lost their
> "etched"ness, this part I am assuming is not a bug but
> probably part of the result of Carlos's style context
> work (probably I'm just seeing un-themed progress
> renderers and treeviewcolumn buttons)...

Yes, I think so too.  There are some more things wrong in the
rendering of GtkTreeView currently. Carlos mentioned to me that he has
some GtkTreeView patches in the queue, so I think we will be fixing
this in the near future.


regards,

-kris.