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

[Kristian Rietveld <kris gtk org>]

On Tue, Oct 26, 2010 at 3:28 AM, Tristan Van Berkom
<tristanvb openismus com> wrote:
> On Mon, 2010-10-25 at 17:26 +0200, Kristian Rietveld wrote:
> Hmm seems I didn't communicate this clearly enough, GtkCellArea
> is a base abstract class, and GtkCellAreaBox is the first concrete
> subclass of GtkCellArea... this allows treeviewcolumn (and other
> layouts) to communicate to the GtkCellArea over some generalized
> apis (i.e. a GtkCellArea does not contain any GtkCellAreaBox...
> together they contain GtkCellRenderers).

Aha! Sorry for misunderstanding.  But then what I said about
GtkCellAreaBox applies to GtkCellArea in general and thus the pull
model is indeed the easiest to go with now.  I understand how you got
into trouble with the CellDataFuncs and also this is solved by going
pull.

> Currently I have it setup so that the GtkCellArea class has
> ->add()/->remove()/->forall() virtual methods that are expected
> to be implemented by concrete subclasses.
>
> Since I've went with the "pull data from a GtkTreeModel/GtkTreeIter"
> api style... already I've implemented:
>  - gtk_cell_area_connect_attribute()
>  - gtk_cell_area_disconnect_attribute()
>  - gtk_cell_area_apply_attributes()

What exactly do these functions accomplish?  Are connect/disconnect
similar to the current add/remove attribute functions?  Typically we
work with one set of attributes per GtkCellLayout, or is this
something you want to change?

> From GtkCellArea base class which requires no cooperation from
> the subclass GtkCellAreaBox (the box only needs to manage it's
> list of renderers and some "expand"/"GtkPackType" attributes,
> then it needs to do it's geometry apis/->event()/->render() etc).

Yep, so we can move all the gory TreeViewColumn details to
GtkCellAreaBox.  I can also do that for you when the GtkCellArea API
takes shape as I am pretty familiar with the GtkTreeViewColumn code
and can perhaps also merge in some of the refactorings (that replace
gtk_tree_view_cell_process_action() with something much saner) I have
on my disk somewhere while at it.


> Also yesterday I gave alot of thought to how height-for-width
> geometry is going to play out in treeviews with regards to cell
> alignments and generally overall size of a GtkCellArea when it's
> size is requested for an arbitrary number of rows.
>
> I'm thinking of trying something like:
>
> /* Subclass creates a class specific 'GtkCellAreaIter' which
>  * can be used to accumulate cell alignments and the overall
>  * sizes when requested for multiple rows
>  */
> GtkCellAreaIter *gtk_cell_area_create_iter (GtkCellArea *area);
>
> Then the request apis get an additional 'iter' context argument,
> it could be for instance that one might use a different 'iter'
> for different depths in the treeview (or to align cells in
> a combo-box menu together in a per submenu context).
>
> gtk_cell_area_get_preferred_width (GtkCellArea *area,
>                                   GtkCellAreaIter *iter,
>                                   GtkWidget *widget,
>                                   gint *min_width,
>                                   gint *nat_width);
>
> The above api would store the resulting overall requested
> width (and cell alignments) in the iter which was created
> by the specific GtkCellArea subclass... however it would
> return a *min_width and *nat_width which is only contextual
> to the GtkCellArea for the specific row-data that is currently
> applied.

Okay, so you need to make sure the specific row data is set first.
(If needed, we could have a likewise iter creation function that also
takes a range of GtkTreePath (start and end) as argument).

Thinking in TreeView terms/compatibility here: the
get_preferred_width() function will be very useful in getting an
initial width for TreeViewColumns, or get the preferred width when
doing "auto size".  I think right now "auto size" will make sure that
"all" contents can be visible (so the width of each column is big
enough for each possible row), but perhaps it makes sense to change
this to the preferred width or have a mode toggle for this somehow.

Outside of that, the width of a TreeViewColumn is mostly fixed.  Also
because a width can be mandated by the user through manual resizing
(and this requirement is trickier than it might appear at first).

How exactly will height handling work?  Height is actually "unbouded"
in tree view, so I guess get_preferred_height() on the GtkCellArea
will not be of use for GtkTreeView, but can be of use for other
layouts of course.  Or will get_preferred_height() return the
preferred minimum height for the scrollable window?

Another idea is that we can possibly make the row validation scheme in
GtkTreeView more efficient (or at least have a slightly cleaner
implementation) by having GtkCellArea measure multiple rows at once
using your API above instead of calling validate_row() separately for
each row.  Though there is a case where we might need efficient single
row measurements from GtkCellArea.  This is in
validate_visible_area(), which as the name might suggest could be
fully handled by GtkCellArea and a range of visible rows instead, but
there is some very intricate scrolling code inside here.

I know the validate_row()/validate_visible_area() code by heart, so
also in this area I can help out by doing this migration.

Finally, we also need support for scrolling support.  Basically
GtkCellArea needs the possibility that the first row is only partially
rendered, so GtkCellArea starts rendering a range of rows at a row +
pixel offset.


> With GtkCellAreaIter we:
>
>  - Cleanup the way that GtkTreeViewColumn bumps its requested
>    width to be the maximum of all previous calls and store that
>    data separately.

I am not really sure how we are going to change this.  Is this just
about the size requisition phase or in general?  If in general, would
the tree view start shrinking columns if needed?

>  - As mentioned above, also allow different alignment contexts
>    to span groups of rows (most plausibly grouped by treemodel
>    "depth").

Depth is likely the best attribute to do grouping on.  I guess the
only alternative would be ranges defined in terms of GtkTreePath, but
that is much more hairy.


regards,

-kris.