Re: GtkTreeView Refactoring Considerations [was Re: Private types inside GTK+]

[Kristian Rietveld <kris gtk org>]

On Sun, Oct 31, 2010 at 7:21 AM, Tristan Van Berkom
<tristanvb openismus com> wrote:
> Ok so I'm pretty much finished the request/allocation code... I've got
> as far as having a list of renderers with allocated positions and sizes
> come time for ->render()/->event() etc.
>
> If I understand correctly about cell_area vs background_area, the
> difference is basically only the focus line width... the reason for
> this is that we want cells to be allowed to fill the whole background
> area with a possible background color before we go ahead and pain a
> dotted focus line over the possibly modified background area.

That the focus line width is the only difference is true as far as
GtkTreeViewColumn is concerned.  Outside of that, there is more,
GtkTreeView will calculate cell_area from background_area taking into
account vertical-separator, horizontal-separator style properties,
depth of the current row, expander indent settings, etc.

> so currently the api on the GtkCellArea only takes a single cell_area
> when rendering, I think thats going to be fine in general and make for
> a clearer API (let me know if I missed something).
>
> So for this I'd like to add a "focus-line-width" property to the
> base class GtkCellArea, and just make the cell area implementations
> always request space for focus-line-width around cells ... then
> come time to render we just create a background/cell_area based
> on the focus-line-width and pass both areas to
> gtk_cell_renderer_render()... I'll do that part presently.

Reversing the calculation, so calculating background_area from
cell_area, will not always work as far as I can see now.  There's more
to take into account than just focus line width as I outlined above.
background_area has slightly different semantics than just cell_area +
focus line width + separators in some cases.  I cannot precisely
answer the question right now, but when reviewing the branch, I will
have to compare GtkCellAreaBox with
gtk_tree_view_column_cell_process_action() anyway, after which I can
go into more detail.  I should perhaps look into bringing this stuff
under unit test at the same time ...

> /* When an allocated width for a height for width treeview changes,
>  * its important to flush out the previous results (or when we
>  * allow the width of the treeview to shrink in consequence of
>  * data updates and we may want to re-request the whole thing),
>  * for this we have:
>  */
> void gtk_cell_area_iter_flush (GtkCellAreaIter *iter);
> void gtk_cell_area_iter_flush_preferred_width (GtkCellAreaIter *iter);
> void gtk_cell_area_iter_flush_preferred_height_for_width
>                                        (GtkCellAreaIter *iter,
>                                        gint             for_width);
> void gtk_cell_area_iter_flush_preferred_height (GtkCellAreaIter *iter);
> void gtk_cell_area_iter_flush_preferred_width_for_height
>                                        (GtkCellAreaIter *iter,
>                                        gint             for_height);

Note that I haven't looked into the actual code yet (hope to get to
that during the week), but one of the questions will be how much data
is exactly cached and how?  GtkTreeView currently employs a RBTree to
efficiently cache/store height data and I think we would want to avoid
having more data structures next to that caching similar or related
data as that might not help performance.  (I am thinking 10000+ row
tree views here).



regards,

-kris.