Adds an attribute mapping to the list in cell_layout. The column is the column of the model to get a value from, and the attribute is the parameter on cell to be set from the value. So for example if column 2 of the model contains strings, you could have the "text" attribute of a GtkCellRendererText get its values from column 2. Since 2.4
Unsets all the mappings on all renderers on cell_layout and removes all renderers from cell_layout. Since 2.4
Clears all existing attributes previously set with gtk_cell_layout_set_attributes(). Since 2.4
Returns the underlying GtkCellArea which might be cell_layout if called on a GtkCellArea or might be NULL if no GtkCellArea is used by cell_layout.
Returns the cell renderers which have been added to cell_layout. Since 2.12
the main Gtk struct as a void*
Adds the cell to the end of cell_layout. If expand is FALSE, then the cell is allocated no more space than it needs. Any unused space is divided evenly between cells for which expand is TRUE. Note that reusing the same cell renderer is not supported. Since 2.4
Packs the cell into the beginning of cell_layout. If expand is FALSE, then the cell is allocated no more space than it needs. Any unused space is divided evenly between cells for which expand is TRUE. Note that reusing the same cell renderer is not supported. Since 2.4
Re-inserts cell at position. Note that cell has already to be packed into cell_layout for this to function properly. Since 2.4
Sets the GtkCellLayoutDataFunc to use for cell_layout. This function is used instead of the standard attributes mapping for setting the column value, and should set the value of cell_layout's cell renderer(s) as appropriate. func may be NULL to remove a previously set function. Since 2.4
GtkCellLayout is an interface to be implemented by all objects which want to provide a GtkTreeViewColumn-like API for packing cells, setting attributes and data funcs.
One of the notable features provided by implementations of GtkCellLayout are attributes. Attributes let you set the properties in flexible ways. They can just be set to constant values like regular properties. But they can also be mapped to a column of the underlying tree model with gtk_cell_layout_set_attributes(), which means that the value of the attribute can change from cell to cell as they are rendered by the cell renderer. Finally, it is possible to specify a function with gtk_cell_layout_set_cell_data_func() that is called to determine the value of the attribute for each cell that is rendered.
GtkCellLayouts as GtkBuildable
Implementations of GtkCellLayout which also implement the GtkBuildable interface (GtkCellView, GtkIconView, GtkComboBox, GtkEntryCompletion, GtkTreeViewColumn) accept GtkCellRenderer objects as <child> elements in UI definitions. They support a custom <attributes> element for their children, which can contain multiple <attribute> elements. Each <attribute> element has a name attribute which specifies a property of the cell renderer; the content of the element is the attribute value.
Furthermore for implementations of GtkCellLayout that use a GtkCellArea to lay out cells (all GtkCellLayouts in GTK+ use a GtkCellArea) cell properties can also be defined in the format by specifying the custom <cell-packing> attribute which can contain multiple <property> elements defined in the normal way.
Subclassing GtkCellLayout implementations
When subclassing a widget that implements GtkCellLayout like GtkIconView or GtkComboBox, there are some considerations related to the fact that these widgets internally use a GtkCellArea. The cell area is exposed as a construct-only property by these widgets. This means that it is possible to e.g. do
to use a custom cell area with a combo box. But construct properties are only initialized after instance init() functions have run, which means that using functions which rely on the existence of the cell area in your subclass' init() function will cause the default cell area to be instantiated. In this case, a provided construct property value will be ignored (with a warning, to alert you to the problem).
If supporting alternative cell areas with your derived widget is not important, then this does not have to concern you. If you want to support alternative cell areas, you can do so by moving the problematic calls out of init() and into a constructor() for your class.