This fixes bug 653289, in gtk+-2 gtk_tree_view_stop_editing() was previously
responsible for notifying with gtk_cell_editable_editing_done(), this detail
was missed when porting the cell renderer management to GtkCellArea.
This commit introduces a new setting, gtk-visible-focus, backed
by the Gtk/VisibleFocus X setting. Its three values control how
focus rectangles are displayed.
'always' is equivalent to the traditional GTK+ behaviour of always
rendering focus rectangles.
'never' does what it says, and is intended for keyboardless
situations, e.g. tablets.
'automatic' hides focus rectangles initially, until the user
interacts with the keyboard, at which point focus rectangles
become visible.
https://bugzilla.gnome.org/show_bug.cgi?id=649567
Having default implementations on abstract classes that do nothing
or print errors make life easier for language bindings implementors,
inside GTK+ this makes little or no difference.
Added _gtk_cell_area_set_cell_data_func_with_proxy() to be called by
gtk_cell_layout_set_cell_data_func() when the layouting object itself
is not the underlying cell area.
The cell's focus rectangle is located around the cell's aligned area.
To get to the correct coordinates for this rectangle, we have to subtract
focus_line_width from the found aligned_area.
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.
- Dont try fetching a cell renderer for an event when the event
coordinate is outside the cell area allocation (can happen
on the y axis, not all events are button events).
- Dont remove focus-line-width (inner area) an extra time from
GtkCellArea->event
- Dont remove focus-line-width from the cell area at all for the
editable widget... use the whole area including the focus line
(compared with git master behaviour and now it looks right, check
the multiline editable string in testtreeedit).
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.
