Since GtkCellArea delegate does all the work, cell layout widgets
who use a GtkCellArea internally only have to implement the _get_area()
method, this just reduces code to forward the calls over the the internal
cell area.
Turns out theres not much reason to do this in a separate api,
now we just sum up the sizes of aligned cell groups in GtkCellAreaContextBox
when pushing the group size.
This is still very much a work in progress, but it renders and more or
less works. I will be fixing up the details in the very near future.
Important: this commit breaks ABI as it modifies the GtkTreeViewColumn
structure in gtktreeviewcolumn.h. This is a sealed structure that needs
to be moved to an internal header file, most likely gtktreeprivate.h.
Slight tweak for GtkTreeView, also non-editable cells must be able to receive
focus to get all keyboard navigation right. This will be further tweaked
to get focus siblings to work like focus cells did in GtkTreeView before
refactoring.
The allocated size, or (horizontally speaking) for-width size, can be
smaller than the sum of all minimum widths. For example when the user
is resizing tree view columns manually.
What this means is basically that a vertically oriented GtkCellAreaBox
will render cells properly even if the height is not constant for every
for of data in the said GtkCellAreaContext (i.e. the height was not allocated
by gtk_cell_area_context_allocate).
This is done completely on the fly and so is much more heavy duty
at render time (considerably slower but not visibly noticable in
lightweight views like GtkTreeMenu). Note that cell alignments
are not possible in an unallocated orientation, each row of data
individually receives only enough space to render the independant
row and no space is reserved for alignments if the size is not
a constant size across rows in the same context.
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.
- gtk_cell_area_context_get_height_for_width()
- gtk_cell_area_context_get_width_for_height()
- gtk_cell_area_context_push_height_for_width()
- gtk_cell_area_context_push_width_for_height()
- gtk_cell_area_context_flush_height_for_width()
- gtk_cell_area_context_flush_width_for_height()
- Contextual size changed signal
All of these are not really important for the CellArea to operate
and not of any real consequential value to the user (the user can
accumulate the returned values from height-for-width requests
and do as they please with it).
This is so that treeviews can have some columns oriented vertically and
some horizontally, usually the column will only allocate the areas
width, having vertical columns without fixed row heights just means
it's slower to render.
Since Havoc's patches introducing the GtkWidget halign/valign
properties, fill should always be TRUE. If the widget should
not fill its allocated space then it should set the halign or
valign properties for that purpose.
This also consequently fixes bug 634592.
It is really bad code, mostly unused and no one stepped up to fix it.
Note that Gtk developers do not object to a ruler widget in priciple,
just to the current implementation. If someone wants to propose a sane
version, please don't hesitate.
https://bugzilla.gnome.org/show_bug.cgi?id=613942
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.
An event filter may add or remove filters itself. This patch does
two things to address this case. The first is to take a temporary
reference to the filter while it is being used. The second is
to wait until after the filter function is run before determining
the next node in the list to process. This guards against
changes to the next node. It also does not run functions
that have been marked as removed. Though I'm not sure if this
case can arise.
https://bugzilla.gnome.org/show_bug.cgi?id=635380
