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

[Kristian Rietveld <kris gtk org>]

On Thu, Oct 7, 2010 at 6:41 AM, Tristan Van Berkom
<tristanvb openismus com> wrote:
> I was thinking that a GtkCellArea would only render a single row
> (actually, a row in a treeview can be composed of several GtkCellAreas,
> each treeview column would use exactly one cell area to abstract a lot
> of the column code).
>
> Now that I look at this again I'm not sure if the GtkCellArea should
> store any information about previous and following rows
>  - should the alignment of cells be stored by the GtkCellArea itself ?
>  - or should it be externalized to some parenting code that pushes
>    the alignment data to the area ?
>
> I think that the former seems more appropriate since only the CellArea
> knows how cells can be aligned for a particular implementation, and
> the initial width/height of cells in the area is also determined by
> the CellArea.

I agree that the former seems more appropriate.  This also paves a way
for doing more flexible layouting in tree view rows.  However, I guess
that we also want to support how cells are laid out right now in
columns and this requires some separate entity to maintain the
alignment and widths for a set of cell areas.

>>  - GtkCellArea (or a subclass) might also have to implement the custom "event-handling" and focus drawing
>> code that is currently in GtkTreeViewColumn.
>
> I think an abstraction api for event handling is simple enough and a
> good fit for a single-row handling GtkCellArea.
>
> gtk_cell_area_event (GtkCellArea  *cell_area,
>                     GdkRectangle *area,
>                     GdkEvent     *event);
>
> This would be implemented by CellArea implementations
> and basically forward the event to the appropriate cell
> renderer according to the area's layout.
>
> I suppose the method for invoking this by treeview for
> instance would be:
>   - Get the appropriate GtkTreeViewColumn for the event->x
>   - The GtkTreeViewColumn would then get the appropriate GtkTreeIter
>     for event->y
>   - The GtkTreeViewColumn would then "push" the data for that
>     column into its delegate GtkCellArea.
>   - Then the GtkTreeViewColumn calls gtk_cell_area_event().
>
> Sounds approximately right ?

It sounds interesting to me and will likely work.  Do note that
currently things are done differently, tree view makes the function
call to "push" the data (though this function is a tree view column
function, so must be possible to refactor this).  Furthermore,
currently not GdkEvents are pushed to the cell renderer, but rather
the "activate" or "start-editing" method on the cell renderer is
called.  I think this lines up well with the plan to have the GdkEvent
only reach the cell area.

> I think that focus painting in this case should be left to the treeview
> and the GtkCellArea continues to return "bounds" of the overall used
> space for it's dedicated GdkRectangle (because the treeview sometimes
> like's to paint focus which spans the entire treeview row... which
> may span several GtkCellAreas for each column; each of which may
> have a different "bounds" in height).

There's also a case in which focus is drawn around a single cell
renderer (that is part of a column together with other cell
renderers).  So this means that either the cell area can draw this
focus, or the exact coordinates of this cell can be acquired from the
cell area.

> Ok good points, you'll notice I left out GtkCellAreaManager comments
> here...
>
> I think you're right that the whole big picture is much and probably not
> reasonable to get done by 3.0.
>
> The best move I think is to break this down into iterations, since my
> immediate concerns are about actual rendering and alignment of cells
> (i.e. achieve height-for-width treeviews and alignment of cells in
> combo boxes)... hopefully I can come up with something good and
> extendable for the GtkCellArea.

Yes, we should definitely break this down into iterations.  Starting
with pushing the cell renderer lay out code from GtkTreeViewColumn
into something like a GtkCellArea sounds like a good start to me.

>
> The concept of row separators and group headings will need some
> thought, I'm not sure it makes sense to chose a different GtkCellArea
> class to render a different row, these cases may be better handled
> as general functionality of the base class (which could be overridden
> by subclasses to achieve a different overall look-n-feel of the
> treeview).

Definitely requires more thought and can, as far as I can see, be done
separately from GtkCellArea.

> I also wonder with some of the offscreen rendering magic recently added
> we can even get GtkButtons to be virtually embedded into a GtkCellArea
> subclass (ofcourse without allocating a separate instance of the
> GtkButton for every row of data being the challenge)... by simply
> rendering the button onto every row...

Interesting idea, and since you want to make it possible to push
GdkEvents into GtkCellArea, the button will also behave appropriately.
 (The event handling was the main issue why you couldn't do something
like a GtkButton in a GtkCellRenderer).


regards,

-kris.