Previously, we considered all LengthPercentage values for used flex
basis to be definite. This is not accurate, as percentages should only
be considered definite if the reference value they resolve against is
a definite size.
Fix this by checking the flex container's main definite size flag.
There's no need to override the sizes before calculating the cross size.
Besides, by the time we're calculating the hypothetical cross size of
flex items, we may already have established a definite main size anyway,
so overriding it would be wrong.
This state is less static than we originally assumed, and there are
special formatting context-specific rules that say certain sizes are
definite in special circumstances.
To be able to support this, we move the has-definite-size flags from
the layout node to the UsedValues struct instead.
Absolutely positioned boxes are handled by the BFC destructor, so we
need to make sure the ICB BFC is destroyed if we want these boxes
to get laid out.
Note that we cannot use CompareTypedArrayElements until the change-
array-by-copy proposal picks up the change to no longer throw with
detached array buffers.
By aligning Array.prototype.sort with the spec, this removes the direct
invocation of CompareArrayElements from array_merge_sort. This opens the
door for TypedArray to use SortIndexedProperties as well because now
array_merge_sort does not assume what kind of array it is invoked with.
Further, this addresses a FIXME to avoid an extra JS heap allocation.
This isn't actually much of an issue because if the LHS side value is -0
and the RHS value is +0, errantly returning 0 in the comparison function
here has the same effect as correctly returning -1. In both cases, the
-0 is left on the LHS.
Remove the static PNG bitmaps we've been using for GUI radio buttons
and replace them with on-the-fly pixel painting.
This fixes a long-standing issue where radio buttons always looked the
same, regardless of system theme settings. :^)
This is not the most useful keyboard binding anyways, plus it will be
extremely hacky to implement it with the generic processor parameter
widgets. Therefore, we'll get rid of it and add back a more generic
keyboard binding system later.
This automatically creates the correct collection of name label, value
label and "editor" (knob, checkbox, dropdown) depending on the processor
type and layouts them vertically.
If we wait until after the parent context has laid out the flex
container, abspos children are able to use the final results of the
parent sizing the flex container.
This makes `height:auto` work on abspos children of a flex container.
Layout cleared the list of bars in the flame graph, but didn't clear the
reference m_hovered_bar. This could cause a crash in mousedown_event()
when clicking twice: the first click caused layout, the second used
the old reference.
This now shows the shortcut to enable mouse pointer highlighting below
the preview. The GML has also been updated to take advantage of the new
layout features rather than using fixed heights.
Previously we would always select the left most column when selecting a
range of rows.
This patch fixes this issue by always applying a selection to the column
in which the selection ends.
AbstractView currently assumes a certain layout of rows and colums to
perform a range selection on.
This patch moves the implementation into a helper that can be overriden
by other views.
We should actually start counting from the parent directory and not from
the symbolic link as it will represent a wrong count of hops from the
actual mountpoint.
The symlinks in /sys/dev/block and /sys/dev/char worked only by luck,
because I have set it to the wrong parent directory which is the
/sys/dev directory, so with the symlink it was 3 hops to /sys, together
with the root directory, therefore, everything seemed to work.
Now that the device symlinks in /sys/dev/block and /sys/dev/char are set
to the right parent directory and we start measure hops from root
directory with the parent directory of a symlink, everything seem to
work correctly now.
All of these conditions should make du just not report the file size
individually, but it should still count them into the grand total.
In the case of the `--threshold` option, this was actually implemented
incorrectly before, as it would report size 0 for files that did not
match the threshold.
We may very well dip into files larger than 4G at some point, so 32-bit
values are not enough, and the 64-bit sized `off_t` doesn't fully make
sense either, as it features negative values.
Instead, switch to the explicit type of `u64` everywhere, which is the
same size on all platforms and is unsigned. The exception to this is
the threshold, which needs to be signed instead of unsigned.
The `--max-depth` option only controls until which depth individual file
sizes are printed, it does not stop the utility from traversing that
branch further (as the file sizes would be wrong otherwise).
Restructure the program to track the current depth, and return early if
the current depth is higher than the maximum allowed depth, which skips
all parts of the logic that are concerned with user output.