Widgets should be given the actual size they will be allocated, so they
can do something with it.
If they want to clamp themselves to their natural size, nothing's
stopping them, they know their natural size after all.
Replace uses of gtk_css_style_get_value with direct access,
throughout the tree. We don't replace all uses, just those
where we are dealing with a fixed property. Be careful to
handle the currentColor special case for color properties.
The reason for this is simply that I want to get hash functions that
have their values close together, so they can fit in a smaller range
(the goal here is 12 bits). By using GQuark, we get consecutive numbers
starting with 1 (and applications have <1000 quarks usually), whereas
interned strings can be all over the place.
As a side effect we also save 64 bytes per declaration.
- Rename GtkLegacyLayout to GtkCustomLayout
- Use for() to iterate over children in GtkBinLayout
- Whitespace fixes for code imported from GtkBox
- Store the GtkLayoutChild instances inside LayoutManager
- Simplify the GtkLayoutManager API by dropping unnecessary arguments
- Fix the ownership model of GtkLayoutManager
We delegate the size request mode, the measuring, and the allocation of
a widget through a GtkLayoutManager instance, if one has been attached
to the widget; otherwise, we fall back to the widget's own implementation.
The transform matrix is a translation matrix from the parent's origin to
the widget origin. We will later allow more transformations than just
translations.
Otherwise, requesting a min size in em where the equivalent in px had a
fractional part would lead to the widget getting allocated 1 too few px.
You could see this in the CSS property vs. allocation in the Inspector.
Note that margin/border/padding are left alone: the rationale is that we
do as browsers do, and Benjamin said we already do that for those,
whereas his tests on min-(width|height) showed otherwise. My subsequent
analysis indicated it to be far less clear-cut than that, but he remains
unconvinced that we should ceil() all the things! So just do these ones.
https://gitlab.gnome.org/GNOME/gtk/issues/1088
Remove all the old 2.x and 3.x version annotations.
GTK+ 4 is a new start, and from the perspective of a
GTK+ 4 developer all these APIs have been around since
the beginning.
Both GtkWidget and GtkContainer had similar docs regarding hfw/wfh
geometry management. Move these just to GtkWidget. Also make sure the
examples compile, port everything from gtk_preferred_* to measure and
replace some occurrences of "container" with "widget" where container
was just used to refer to a widget with child widgets.
The GtkWidgetClass::measure vfunc is not required to assign a value to
any of the (out) parameters, so we need to initialize the locals we pass
to it, otherwise we can end up with a garbage size request.
The reported minimum baseline is for the reported min height, but if the
css min-height is greater than that, we need to account for that fact
when saving the baseline.
Since the reported baseline is relative to the widget's origin, we also
need to add the top values for margin, border and padding to the
reported baseline.
We need to adjust the passed for_size to fit into the content allocation
of the widget.
That also means that we can't call gtk_widget_measure(widget) inside
gtk_widget_measure(widget) since now the for_size will be adjusted
twice.
Instead of mentioning the old _get_preferred_xxx functions, mention
measure() and print the for_size value as well. The orientation is given
by printing either "width" for GTK_ORIENTATION_HORIZONTAL or "height"
for GTK_ORIENTATION_VERTICAL.
Add a new ::measure vfunc similar to GtkCssGadget's that widget
implementations have to override instead of the old get_preferred_width,
get_preferred_height, get_preferred_width_for_height,
get_preferred_height_for_width and
get_preferred_height_and_baseline_for_width.
