Add a "Change direction" menu item that toggles the widgets
direction, to give the user control in the rare cases where
a different direction is appropriate.
The same action can by triggered by the shortcut Ctrl-Shift-T.
Instead of trying to derive a direction from content and
keyboard layout, just let the widgets direction prevail.
This avoids irritating jumping text on focus in, in situations
where the directions are mixed.
See discussion in !7971
In gtk_box_layout_compute_opposite_size (), the box layout performs a
binary search to find the minimum size that would fit its children.
Specifically, distribute_remaining_size () would pick a proposed size
in the opposite orientation, measure every one of the non-constant-size
children for that size along the box's orientation, add their minimum
size requests, and see if it fits the original for-size value; based on
the outcome, it would then consider a larger or a smaller answer.
Note specifically that this always measures the children of the box
along the box's own orientation, even though the box itself is being
measured in the opposite orientation. This can be a good thing or a bad
thing: for instance, if a vertical box containing labels is being
measured width-for-height, the box will binary search for the minimum
width and the labels will be measured height-for-width, which is their
preferred size request mode. If, on the other hand, a horizontal box
containing labels is being measured height-for-width, the box will
binary search for the minimum height, and measure the labels width-for-
height, which is the worst situation possible, since the labels will run
their own binary search to measure themselves that way.
Add a special case code path for the case of a box containing two
variable-size children being measured against the box's own orientation,
but in accordance with their preferred size request mode. In this mode,
the box will instead binary search for the optimal way to split the
available space along the box's orientation among the two children.
For clarity, let's say that we're dealing with a horizontal box
containing two height-for-width children.
It is possible to use binary search this way because of the following
observation:
Suppose we pick some way to split the available width, i.e. some amount
of available width to allocate to the first child, the rest of the width
being allocated to the second child. We then measure the minimum height
of both children for these widths. Suppose the first child requires more
height. Then the only way we could possibly get a better answer (a
smaller minimum height for the box) is by giving more width to the first
child, which may or may not regress the second child's minimum height.
Similarly, if the second child is taller, the only way we could improve
on the result is by giving less space to the first child and more space
to the second child. If both children have the same minimum height, we
can not improve the answer in any way.
It is possible to generalize this algorithm for the case of > 2 child
widgets, but it is significantly more complex, and hits diminishing
returns. Here's the idea of the generalized algorithm anyway:
Between the steps of the search, the state we track is the minimum
amount of width that we're considering allocaitng to each individual
child, i.e. int width_at_least[N]. Of course, the sum of widths cannot
exceed the available width. Initially, the width for each child is equal
to the overall minimum width of the child.
At each step, we consider a way to assign widths to the children.
Specifically, we distribute the remaining (yet undistributed) width
budget among all the children equally (or almost equally if the
remaining width is not a multiple of the number of children), adding it
to the already committed width distribution. We then measure each
child's minimum height for that width, and find out which child requires
most height. The only way we could improve the answer relative to that
point is by giving that child more space. Thus, we commit the amount we
allocated to that child, but not to the others. By doing this, we split
the search space "in half". We then proceeed to the next iteration.
Once there are less units of available width left than the number of
children, we no longer can give *some* additional width to every child
all at the same time, so the final stage of the algorithm will have to
use a different strategy to still make progress: track the height of
each child at the width currently committed to it, and commit one unit
of width to the tallest child, re-measuring it for the new width.
This algorithm reduces the search space by N / (N - 1) times on each
iteration (which is by 2 times for N = 2), so it would need about
log(width, N / (N - 1)) = log2(width) / log2(N / (N - 1))
iterations to converge, with log2(N / (N - 1)) gowing closer to 0 as N
grows, thus the number of iterations growing unboundedly. And each
iteration needs to measure each of the N children once.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
When all of the following are true:
1. the layout is not homogeneous,
2. there is a single inconstant-size child,
3. all the constant-size children (if any) report minimum = natural
along the box's orientation,
4. none of the constant-size children should be expanded,
5. the inconstant-size child should be expanded,
we can go ahead and allocate all of the space remaining after
subtracting constant-size children's sizes and any spacing to the
inconstant-size child. Notably, we don't even have to measure it, which
can be a serious win if we would be to measure it against its preferred
size request mode (e.g. width-for-height for a height-for-width widget
such as a GtkLabel).
This is an "allocation passthrough" optimization, mirroring the "measure
passthrough" optimization implemented in the previous commit: the
allocation given to the box is passed through to the inconstant-size
child after subtracting the space for its constant-size siblings. Unlike
the measure passthrough, this is only applicable under specific, yet
common enough, circumstances listed above.
The specific case this is meant to address is a horizontal box with some
constant-size children and an hexpand wrappable label (seen e.g. in
GtkTooltipWindow). With this patch, allocating the box avoids measuring
the label at all, while previously it would be measured width-for-
height.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
Add a fast path for the very common case of having a single inconstant-
size child, possibly along with several constant-size children. In this
case, we can avoid doing the binary search, and just query the child
itself for its minimum size for the available size. As a bonus, in this
case we're measuring the child in the same orientation that the box is
being measured, and not the opposite orientation like the binary search
does. Since the box propagates its child's preferred size request mode,
ancestor widgets will hopefully prefer to measure the box in the same
orientation that the child prefers, and we're now measuring the child
for the same orientation instead of inverting it.
This is in many ways like "passing through" a measure call to the single
inconstant-size child, while subtracting the space required for other
constant-size children, and doing the usual aggregation of the results
in the end.
For the common case of many many layers of nested boxes of alternating
orientations which all add constant-size "decorations" around a central
wrapping label, this cuts down on the number of Pango layouts required
to lay things out dramatically. A reftest for such a case is included.
See these Fractal [0] and Paper Plane [1] issue reports about the severe
performance issues caused by the many layers of nested boxes performing
binary searching.
[0]: https://gitlab.gnome.org/GNOME/fractal/-/issues/1183
[1]: https://github.com/paper-plane-developers/paper-plane/issues/379
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
When measuring opposite-size-for-minimum-size, we can quickly see that
there is only a single way we could distribute space among our children,
and that is assigning to each child its minimum size. No need to run the
binary search or distribute natural allocation in this case.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
...and separate it from minimum opposite size-for-size computation.
Previously, the two were intertwined.
In broad terms, gtk_box_layout_compute_opposite_size_for_size () gathers
minimum and natural size requests of the child widgets *along* the box's
own orientation, and then uses gtk_distribute_natural_allocation () to
distribute the available size (the size being measured for, minus any
spacing) between them. This mirrors what gtk_box_layout_allocate () does
to distribute the allocated size. Once the available space along the
box's orientation has been distributed and a size assigned to each
child, gtk_box_layout_compute_opposite_size_for_size () measures
children in the opposite orientation for those sizes assigned to them,
and then does the usual aggregation (namely, MAX + baseline handling) on
the resulting list of size requests.
In commit 76c4673944 "boxlayout: Fix
broken min-size-for-opposite-size", it has been discovered that simply
distributing available size based on the size requests in that one
orientation -- the way that gtk_distribute_natural_allocation () does it
-- leads to reporting incorrect minimum opposite size. This is not an
issue during allocation, since there, the size requests of the children
already account for the available space in the other orientation. To fix
this for the measurement logic, a new code path was introduced that uses
binary searching to reliably discover the minimum size in the other
orientation.
The minimum size found by the binary search, however, was not getting
directly used to report the box' minimum size. Instead, the size
requests of child widgets would get measured based on the discovered
minimum size (just as they are during allocation), and then fed into the
generic gtk_distribute_natural_allocation-based logic described above.
Since minimum size is (assumed to be) monotonic, and both distributing
extra space towards natural sizes and applying expand flags could only
increase the size of the children along the box's own orientation, the
minimum size in the opposite orientation that got computed should match
the one that was found during binary searching.
But there are still issues with this. For one thing, the implementation
had a bug, in that it wouldn't actually re-measure size requests based
on the final minimum size discovered during binary searching; instead,
it would use the values left in sizes[i].minimum_size and
sizes[i].natural_size by distribute_remaining_size (). Those were indeed
often the measurements for the found minimum size (in case the last
iteration of the binary search accepted the candidate size). In case the
last iteration took the other branch, ruling out the candidate size,
those leftover measurements would simply be incorrect, and the box would
likely end up reporting minimum opposite size being smaller by 1px
compared to the correct value. This is a simple bug in the code and not
a fundamental issue with the approach.
A more serious issue is the following: the distribution of child sizes
along the box's own orientation that achieves minimum size in the
opposite orientation might be quite different from the one that would be
considered "natural", as in describing the layout that produces the
natural size in the opposite orientation. For a specific example,
cosider a box containing a wrappable GtkLabel and a GtkPicture. Since
the picture's minimum size is 0 (assuming can-shrink is not unset), the
layout that achieves minimum size in the opposite orientation is the one
that gives the label as much size along the box's own orientation as the
label is able to make use of, only assigning the remaining part (if any)
to the picture. Moreover, the actual size assigned to the picture may be
even smaller than the remaining part, since the picture's natural size
request will be measured based on that (small) minimum size in the
opposite orientation, and the picture expanded from its minimum size of
0 up to that size. Measuring the natural size in the opposite
orientation will then likely produce the same value as the minimum size
again. This will happen even if the available size in the box's own
orientation was enough to fit the label and the picture at their natural
sizes, which would then allow them to ask for their full natural sizes
in the opposite orientation. The only reason for this is that for
measuring the natural size, we picked a size distribution that was
optimized for producing the smallest possible minimum size, and one has
little to do with the other.
Similarly, consider the case of a horizontal box containing a label that
has its natural width limited by setting max-width-chars. Such a label
is able to make use of more horizontal space than its natural width to
reduce its height request, when that is required. By computing the
minimum height possible and considering label's minimum and natural
widths for that height as the basis for the following distribution of
available width, we'll force the label to take up more width that its
natural size even though we're not actually vertically constrained,
which will then result in it asking for less height than its normal
natural height.
The reftests added in this commit demonstrate the issues in the cases
described above.
Moreover: there is an optimization that we'd like to implement, namely
it should be possible to avoid the binary search in case of a single
inconstant-size child, and instead ask the child about its minimum size
directly. However, in order to fit this approach into the existing
gtk_distribute_natural_allocation-based logic, we have to rely much more
on the child widget reporting consistent width-for-height and height-
for-width measurements. An initial attempt to implement this
optimization, https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6569,
ran into many cases where this just wasn't so in practice, which broke a
number of layouts, and while specific individual cases of inconsistent
measurements are being fixed, merging this optimization is just not
feasible. Separating computation of minimum and natural sizes allows the
direct measurement of a single child optimization to only affect the
computation of minimum size, without either breaking natural size or
running into contradictory measurements.
So, this patch does just that.
distribute_remaining_size () no longer fills sizes[i].minimum_size and
sizes[i].natural_size; it now only calculates the minimum size, and that
calculated size is used directly for the reported minimum size of the
box. gtk_distribute_natural_allocation-based logic is only used for
measuring the natural size in the opposite orientation, and the minimum
and natural sizes passed to it are just overall minimum and natural
sizes. (The produced layout is still kind of being used for measuring
baselines, but those are hopefully only used with constant-size
children, whose baseline and size doesn't depend on the distribution.)
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
...when doing height-for-width as well. This follows up on the original
change made in commit 6b59c138b2.
Note that baseline alignment, when it is enabled, is unlikely to work
with widgets that trade height for width. This is because, while the
width request in is assumed to monotonically decrease as the available
height is increased (though even this turns out to not always be true),
the same can not be guaranteed about baselines, which would prevent the
binary-search based layout algorithm from discovering the optimal way to
distribute the available space between child widgets.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
In the "GtkExpression in .ui files" section, mention that you can create
a property lookup for the "this" object by leaving the <lookup> element
empty.
When interpolate-size is set, we interpolate the stack's size request
from the last allocated size to the newly visible child's size request,
while the transition is running. This hopefully causes ancestor widgets
to smoothly change the allocation of the stack, and the user sees a
pretty animation.
To keep the layout from breaking, we need to report consistent width-
for-height and height-for-width measurements throughout the transition.
Our parent can measure us passing any valid for_size, and we need to
keep the responses consistent. This is complicated by the fact that
while we know the current progress of the transition and which size
we're animating *from*, we don't know which size we're animating *to*.
We base our measurements on those of our child, the one we're animating
towards, with lerp applied on top. When we're interpolating size in both
orientations (as opposed to staying homogeneous in one of them), we must
also adjust the for_size before we pass it on to the child, in order to
"undo" the lerp we would have done when being measured in the opposite
orientation. This is similar to what GtkRevealer does.
This is notoriously tricky to get right (which took me more than a
year), in particular:
* we have to handle for_size == -1 specially,
* we have to handle progress == 0.0 specially,
* we have to make sure the result of inverse_lerp is reasonable, and
handle the case when it's not,
* we have to round down the result of inverse_lerp, and round up the
result of lerp.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
Like what is done in the libRSVG CI, install (and update) Rust as we need it to
build accesskit-c.
This is the Visual Studio part to address issue #7211.
We generally much prefer height-for-width over width-for-height, since
the former is typically better supported and faster, and the latter is
known to cause issues, most notably with wrappable labels. So when we
have two children with differing preferences and so have to make an
arbitrary choice between the two, prefer height-for-width.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
We don't generally care about hidden (or native) children when
performing layout, as is indeed suggested by the should_layout () method
name. Specifically for determining request mode, we'd like to return
constant size whenever we can, since this can result in very valueable
performance gains when measuring ancestor widgets. In case we have some
visible constant-size children and some hidden height-for-width ones,
we can still return constant-size.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
