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
In the current introspection data, the various gtk_radio_button_new_*
constructors take an existing group or widget. These all allow passing a NULL
widget or group list, so that it becomes easy to build a radio button list in a
loop (pass in None the first time, and the previously created button in all
other iterations).
Add the missing "allow-none" tag to the introspection data, so that this will
also eventually work for GIR users. NB that it does not actually work for some
constructors yet (like new_with_label_from_widget()) due to
https://bugzilla.gnome.org/show_bug.cgi?id=561264.
https://bugzilla.gnome.org/show_bug.cgi?id=635253
Since what we are doing is turning an icon with alpha into a
no-alpha icon + mask for legacy window managers, it makes more sense
to use the system visual than the window's visual, which might
be ARGB.
https://bugzilla.gnome.org/show_bug.cgi?id=634821
