Added gtk_cell_area_context_get_preferred_height_for_width and
width_for_height & gtk_cell_area_copy_context() to gtk.symbols
and gtk3-sections.txt (also finished up documenting those apis).
Added a few apis,
- GtkCellAreaContext get_preferred_height_for_width &
width for height apis and vfuncs, this lets the icon view
request the collective (and aligned) height for width for
a said row.
- gtk_cell_area_copy_context() this creates a duplicate of
an already created and requested context, this way the icon
view uses a global context to request the widths of all rows
and then makes a copy with all the stored alignments and
uses a separate copy to calculate the height and alignments
of each row separately.
This argument allows the caller to specify that only an editable
cell should start editing but an activatable cell should not toggle
it's state, this is important for public apis like
gtk_tree_view_set_cursor_on_cell() which are only intended to
programatically bring attention to the editing of a specific
row or cell but not actually change any data.
GtkTreeView & CellAreaScaffold updated for the last minute api change.
This allows us to reduce code allocation code paths in subclasses, as
a result GtkCellArea implements the ->render() vfunc and the subclass
only decides the cell area and background area distributions in a single
code path.
gtk_cell_area_foreach_alloc() itterates over an allocated list of cells
and calls a callback with the cell's allocation until the callback returns
TRUE.
- Removed vfunc get_cell_allocation() and implemented
gtk_cell_area_get_cell_allocation() using foreach_alloc()
- Added gtk_cell_area_get_cell_at_position() using foreach_alloc()
- Removed GtkCellAreaBox ->event() implementation and implemented
mouse "click" cell activation in GtkCellArea class directly using
gtk_cell_area_get_cell_at_position().
This is because focus in treeviews can be given to cells that cannot do anything
with activation (for better keynav), so we dissociate the concept of cell
activation and focusing.
Since a cell renderer might use more space than the natural
size when recieving expand space it's impossible to know how
much space is actually used to render content.
Adding this virtual method to allow text renderers to implement
it, the base default method uses height-for-width apis and aligns
the cell assuming the renderer uses a fixed size.
This commit removes the similar code from gtkcellarea and
subclasses.
Made gtk_cell_area_apply_attributes use a vfunc & signal so that
subclasses might do specialized things picking up attributes from the
model possibly for embedding widgets, and as specially for GtkTreeMenu
to connect to the signal and synchronize the menu sensitivity states
in a more convenient way than going through the GtkCellLayoutDataFunc.
- Added gtk_cell_area_aligned_cell_area() to get the aligned
internal area use by a cell (for focus painting and for
event areas).
- Provide the event area in "editing-started" signal
- Fire "remove-editable" when editing is canceled by the user,
an implementing layouting widget need only catch "editing-started"
and "remove-editable" now.
- CellAreaScaffold/testcellarea now edit textrenderers.
Now GtkCellAreaBox handles the click event to activate renderers
and checks if the area is in a sibling of a focus renderer, possibly
activating the proper focus sibling renderer.
Also GtkCellArea gains a "focus-changed" signal to allow it to
change the currently focused row according to the button events.
Added concept of "Focus Siblings" to GtkCellArea so that some
static text/icon may be included in the focus/click area of
an activatable or editable cell, implemented focus drawing
as well, updated testcellarea to reflect the changes.
Now when the GtkCellAreaBox receives key events it cycles
the currently focused cell to the next focusable cell in the box
while observing the navigation direction, it then emits "focus-leave"
when hitting the boundries of the area.
Now:
- The current edit cell and editable widget in use can be fetched
with properties and accessors
- gtk_cell_area_activate_cell() handles bookkeeping of the currently
edited cell, starting the editing of a cell, activating a cell etc
- Exported signals are available on GtkCellArea: "editing-started",
"editing-canceled", "editing-done", "remove-editable".
- Upon receiving GDK_KEY_Escape current editing gets canceled.
- Added vfunc to get the allocation of a cell inside an area
- Superclass GtkCellArea handles activation of focused cells
by handling key events (as well as editing of editable cells)
- Added signal "editing-started" to GtkCellArea to signal that
editing has started (generally signaled from inside event handling)
- Added properties "focus-cell" and "edited-cell"
The state of expanded cells must come from the view, since these states
can vary across views accessing the same model (also "finished up" the
applying of attributes code).
The rationale here is that every cell in an area needs to have space
reserved around it, requests have to be fully margin inclusive...
cells need to have the full size fed as the "background area" and
the "cell area" has margins removed... This will be used by GtkTreeViewColumn
to set the focus line width so that cells can paint a background on the
full background, then render themselves into the cell area... and parents
can go ahead and draw focus and other indicators on the background area
but outside of the cell area.
Added base class to hold alignment and overall size request information
while itterating over the size requests of various rows of a GtkTreeModel,
updated GtkCellArea/GtkCellAreaBox classes accordingly.
Now GtkCellArea handles attribute connections in the base class,
subclasses only need to add/remove the renderers, render them,
do geometry and handle events.
Now GtkCellArea provides a generic way of applying attributes
from a GtkTreeModel/GtkTreeIter, GtkCellArea bookkeeps a hashtable
of GtkCellLayoutDataFunc's and completely abstracts the applying
of data to cells... GtkCellArea implementations need only to bookkeep
the added renderers and attributes (probably we can abstract the
attribute bookkeeping in the base class as well).
Things starting to take a good and practical shape.
