Re: GtkTreeView breakage in master

[Carlos Garnacho <carlosg gnome org>]

Hi!,

On Sun, 2010-12-05 at 14:33 +0100, Kristian Rietveld wrote:
> 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.

Apparently cairo_scale()'ing by 0 made everything go nuts, a dimensional
warp?, I've added some sanity check to the coordinates passed to
gtk_render_* calls.

> 
> 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.

Yes indeed, there is code in gtkstyle.c to translate detail strings to
stuff GtkStyleContext understands, but I think it makes sense to bear a
bit with this as we switch to the definitive thing.

> 
> 
> regards,
> 
> -kris.
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list