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.
Ultimately we should not panic just because we can't fully commit a VM
region (by populating it with physical pages.)
This patch handles some of the situations where commit() can fail.
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 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 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 a window is maximized by clicking the 'maximize' button in the window frame,
the WindowFrame *is* invalidated and repainted properly. However, the internal
state of the WindowServer::Button does not get updated until the next mouse
movement. This means that the 'maximize' button is erroneously highlighted until
the mouse moves again. This is very visible.
Ideally, a patch should compute the actual new m_hovered. However, this requires
knowledge of the new rect, or calling something on the Button after the new rect
has been determined. Until someone can figure out a good way around this,
setting m_hovered to false is a solution that 'usually' works.
Note that this does *not* work when after maximizing/restoring, the maximize
button falls exactly under the mouse again. The button functions properly, but
is erroneously not highlighted.
At least a *missing* highlight is less noticable than a highlight too many.
ComboBox creates a regular (non-modal) window; I believe this is fine.
A Dialog (modal window) can contain a ComboBox; I believe this is fine.
A non-modal child window of a modal window (e.g. a ComboBox pop-out within
a Dialog) wasn't clickable, and was blocked in the WindowManager.
I want to change this behavior.
This edge case occurs when trying to select a month in the "Calendar"
Application.
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
