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

[Tristan Van Berkom <tristanvb openismus com>]

On Sun, 2010-10-31 at 17:45 +0100, Kristian Rietveld wrote:
> On Sun, Oct 31, 2010 at 3:17 PM, Tristan Van Berkom
> <tristanvb openismus com> wrote:
> > Whew, ok I implemented GtkCellArea->render for GtkCellAreaBox for the
> > most part, however I'm still missing the GtkCellRendererState flags ;-)
> >
> > So for this part I was thinking it might make more sense to create
> > a new GtkCellAreaStateFlags type with just per-row states (and add that
> > as an argument to GtkCellArea->render() and also GtkCellArea->event())
> 
> Most of the states in GtkCellRendererState are actually per-row states
> already (selected, focused, etc.) and are toggled by GtkTreeView and
> GtkTreeViewColumn when rendering the cells.  Though one state,
> "sorted", is obviously per-column.  Did you mean to have a new
> GtkCellAreaStateFlags that will have flags per *cell area* and thus
> per *column*?

Ah no I meant per row, I was just seeing how treeviewcolumn does
some hackery around the FOCUS flag (i.e. when treeview column
receives the focus flag at render time, it immediately unflags
that and then re-applies the FOCUS bit to the renderer flags
for actual renderers it decided were to be passed the focus
flag).

I suppose that the "sorted" flag also spans the whole column
and not a single cell... since a column can be composed of
one cell area (or even potentially more than one, but lets just 
consider one area per column)... I suppose that all of the flags 
defined by GtkCellAreaStateFlags are interesting to pass along 
to the cell area at render/event time.

> 
> > and then somehow tidy up the code that in GtkTreeViewColumn is
> > currently:
> >
> >  _gtk_tree_view_column_count_special_cells (tree_column)
> 
> This function is part of implementing the key navigation behavior.  A
> "special" cell is one that is editable or activatable.  The rule is
> that if there's a single special cell in a column, a focus rectangle
> is drawn spanning all cells in that column.  If there is more than one
> than the focus rectangle will be drawn around single cells.  This
> works fine in many cases, but can of course be awkward in a few
> situations, so perhaps we want to make this configurable in the
> future.  The same likely holds for a situation where you have a check
> box cell renderer and text cell renderer next to each other in a
> column:
> 
>    [x] [my label in a text renderer]
> 
> Akin to a GtkCheckButton, you would want the check to toggle when the
> text renderer is clicked.  And it would be natural if the focus
> rectangle spans the check box and the text renderer. But in other
> situations, with different cell renderers, you do not want this.  This
> is also something to think about and improve for the future.
> 

Ah ok this clarifies things... I suppose if cell is activatable
or editable then it CAN_FOCUS :)

I'll look into this ... I guess the treeview itself will have
to (and already does) I'll look into how cell areas can handle
their own internal focus chaining... probably they have to 
notify the caller (treeview/column) that focus should be passed 
to a leading or following column (or cell area), track the
currently focused cell etc.


> I think the GtkCellArea will also allow us to get rid of
> _gtk_tree_view_column_get_cell_at_pos(), which I have never really
> liked for some reason.
> 
> 
> > For focus handling and such I guess it will probably make sense to add:
> >
> >  GtkCellArea->set/get_focus_cell()
> 
> That could work if there is the possibility to set focus around all
> cells in the GtkCellArea as well and to disable focus for a given row
> (if there are no "special" cells in a row, then a focus rectangle is
> drawn around the entire row).

Right, I think that the "focused cell" only needs to be called once
and is a global state for all rows, however at ->render() and ->event()
time the focus handling is ignored for 'flags' that dont contain
the FOCUS bit.

The cell area itself should be smart enough to flag all the appropriate 
cells with the FOCUS bit when rendering for a row (in other words things
dont really change too much from how treeview column processes this,
only that we have some added focus handling).

> > Which is currently missing... then I suppose from ->event() if the row
> > for which an event is handled itself has focus, it will make sense to
> > activate the focused cell.
> 
> I would follow the way GtkTreeViewColumn is currently handling this
> for now.  Because when clicking on a check box renderer on a row that
> does not have focus (and focus in tree view only really plays when you
> are using key navigation), the click should likely activate the check
> box renderer anyway.

Ah yes I was not so clear, I meant specifically for handling key
events... the base GtkCellAreaClass would be responsible for
activating a focused cell if present, when processing the ENTER 
key on a focused row... if the base class did not do anything;
the subclass GtkCellAreaBox will go ahead and process mouse events,
thus activating the right renderer directly (as well as giving the
appropriate cell "focus").

Thanks a lot for your insights and help !

Cheers,
      -Tristan