| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
This is a workaround for the silly issue where some content would move
one pixel upward on every layout. The block layout code was finding
the list item marker and doing regular inline layout on it. We were not
prepared to handle this, which caused it to move in a silly way.
For now, just regenerate markers on every layout to work around the
issue. In the future we should figure out a nice way to layout markers.
|
|
It didn't feel right to have a "DHCPClient" in a "Servers" directory.
Rename this to Services to better reflect the type of programs we'll
be putting in there.
|
|
We never want to store null messages, so make it impossible to do so.
|
|
This is consistent what we do for regular Buttons and gives a pleasant
visual cue when you're over a clickable area.
|
|
I'm not sure how this even _builds_
|
|
This (seemingly) no-op cast communicates our intention to clang
|
|
|
|
|
|
|
|
|
|
The existing scanline method works just fine, and only needs the points
to be available as floats.
This commit reverts the complex polygon mitigation, and instead fixes
the rasterization process to avoid generating complex polygons because
of precision issues.
|
|
This simplifies building composite widgets by not having to worry about
updating widget subtrees.
|
|
This allows the painter to render filled complex shapes better, by
constructing a path graph for (interesting) intersecting lines and
omitting lines from the containing segments if they are detected
to take no part in defining the edges of a shape.
This approach would still fail if there are multiple logical shapes
that are confined to the collection of lines.
For instance, two polygons intersecting each other in a way that one
vertex of polygon A ends up inside polygon B.
we would detect that polygon A's edges are part of the shape
(technically correct) even though they are not a part of polygon B at
all.
|
|
|
|
|
|
|
|
The ECMAScript spec defines multiple equality operations which are used
all over the spec; this patch introduces them. Of course, the two
primary equality operations are AbtractEquals ('==') and StrictEquals
('==='), which have been renamed to 'abstract_eq' and 'strict_eq' in
this patch.
In support of the two operations mentioned above, the following have
also been added: SameValue, SameValueZero, and SameValueNonNumeric.
These are important to have, because they are used elsewhere in the spec
aside from the two primary equality comparisons.
|
|
|
|
This can be used to get a ByteBuffer that wrapps the section's data.
|
|
|
|
This required 2 changes:
1. In the parser, create a new variable scope, so the variable is
declared in it instead of the scope in which the 'for' is found.
2. On execute, push the variable into the newly created block. Existing
code created an empty block (no variables, no arguments) which
allows Interpreter::enter_scope() to skip the creation of a new
environment, therefore when the variable initializer is executed, it
sets the variable to the outer scope. By attaching the variable to
the new block, the block gets a new environment.
This is only needed for 'let' / 'const' declarations, since 'var'
declarations are expected to leak.
Fixes: #2103
|
|
|
|
When calling a function with a tagged template, the first array that is
passed in now contains a "raw" property with the raw, escaped strings.
|
|
In the TreeView, the background of the selected line (or any background,
really) was only drawn until the frame's width. When the text was larger
than the frame's width, this caused the end of the text to be displayed
without background, making it unreadable if it was white (which is the
default text color for selected lines).
To compute the background width, we have a choice between :
- The inner frame width (the current behaviour which causes the issue)
- The total width of all columns (which causes the background to end
early if the columns don't cover the full width)
The new algorithm uses the biggest of the above values, which gives us
exactly what we want in all cases :^)
Fixes #2134
|
|
|
|
This avoids repeated traversals of the underlying words and gives a
30% speed-up on "test-crypto -t pk" :^)
|
|
As spotted by @heavyk this was missed in 57b2b96.
|
|
|
|
|
|
This should go away when we get the ability to parse strings to
DateTime's.
|
|
|
|
StringView::to_string() was added in 917ccb1 but not actually used
anywhere yet.
|
|
Adds support for the following syntax:
myFunction(...x, ...[1, 2, 3], ...o.foo, ...'abcd')
|
|
"[Function.length is] the number of formal parameters. This number
excludes the rest parameter and only includes parameters before
the first one with a default value." - MDN
|
|
|
|
This implements only one of the two forms of this function,
ctx.fill(winding_rule).
Also tweaks the quadratic curve demo to have a nice looking filled
shape.
|
|
There are some imperfections with intersecting edges (because the main
algorithm used is scanline, and that is not geared towards drawing
complex shapes), however, it behaves mostly fine for normal use :^)
|
|
To make processing tagged template literals easier, template literals
will now add one empty StringLiteral before and after each template
expression *if* there's no other string - e.g.:
`${foo}` -> "", foo, ""
`test${foo}${bar}test` -> "test", foo, "", bar, "test"
This also matches the behaviour of many other parsers.
|
|
|
|
A regression was introduced in dc9b4da where the parser would
incorrectly parse the assignment of arrow functions to (non-declaration)
variables. For example, consider:
a = () => {}
Because the parser was aware of default parameters, in
try_parse_arrow_function, the equals sign would be interpreted as a
default argument, leading to incorrect parsing of the overall
expression. Also resulted in some funny behavior
(a = () => {} => {} worked just fine!).
The simple fix is to only look for default parameters if the arrow
function is required to have parenthesis.
|
|
This allows others to reuse the existing connection to ProtocolServer
instead of creating a separate one.
|
|
|
|
|
|
These are just clones of the Rect equivalents.
|
|
At that point, it seems unlikely that the shape is gonna be shared with
other objects, and we avoid getting stuck holding a big bag of shapes.
|
|
This display type is implemented using a LayoutBlock that is_inline().
Basically it behaves like a block internally, and its children are laid
out in the normal block layout fashion. Externally however, it behaves
like an atomic inline-level box.
Layout of inline-block boxes happens in three stages:
1. The outer dimensions of the block are computed during the recursive
normal layout pass. We skip positioning, but lay out children.
2. Later on, during line layout in the *containing block*, the inline
block now contributes a linebox fragment. When linebox fragments are
positioned, we learn the final position of the inline block. That's
when we set the inline block's position.
3. We re-layout the inline block's children once again. This is done to
make sure they end up in the right position. The layout tree doesn't
use relative offsets, so after we position the inline block in (2),
its children will not have its positions updated. Relayout moves
all children of inline blocks to the right place.
This is a rather naive approach but it does get the basic behavior into
place so we can iterate on it. :^)
|
|
|
|
|
