Once we've generated enough lines to make it past all the floating
boxes on either side, just forget those boxes. This simplifies the
available space computation since we don't have to consider boxes
that can't vertically intersect the current line anyway.
After we've cleared past some floating elements, we should not keep
stacking new floats horizontally.
Instead, new floats after the clear should once again start at the
left or right edge of their containing block.
Within the same stacking context, positioned elements must be painted
after non-positioned ones.
I added a Layout::Node::for_each_child_in_paint_order() to help with
this since it's also needed for hit testing.
The BFC "context box" is now the outer box of the block formatting
context. Previously the context box was always the current target box,
which made it hard to reason about who was really the containing block
of whom in various places.
Note that IFC still has the containing block as its context box, this
change only affects BFC. However, to clarify the situation in IFC,
I've added a containing_block() getter than returns the context_box().
Instead of plowing through all the floating boxes within a BFC and
doing all the layout up front, do the children of each block as we go.
This will allow us to know the vertical position of the containing
block when placing floats.
This changes the remaining uses of the following functions across LibJS:
- String::format() => String::formatted()
- dbg() => dbgln()
- printf() => out(), outln()
- fprintf() => warnln()
I also removed the relevant 'LogStream& operator<<' overloads as they're
not needed anymore.
Formatter<char> internally uses Formatter<StringView> when in
Mode::Character, but that would only accept Mode::{Default,String} and
ASSERT_NOT_REACHED() otherwise, causing String::formatted("{:c}", 'a')
to crash
This patch adds an option to the menubar for exporting the current
game as a PGN file. This file can then be read by other chess
programs (and ours eventually) to replay the game or analyze it.
The implementation is mostly PGN spec compliant, however the code
could use some more work. Particularly the `const_cast`s...
But it's a start. :^)
Fixup: Chess: Fixed hard-coded home path in unveil() call
Fixup: Chess: Removed castling flags from Move struct
The castling detection logic is done inside Move::to_algebraic()
now, removing the need for is_castle_short and is_castle_long flags
inside of the Move struct.
As much as I like the "test" piece set, I think "stelar7" is a much
better first impression for anyone opening the Chess game, so I
consider it a much more sensible default.
Fixes a regression introduced by 5c1b3ce. The commit description there
asserts that the changes allow calling will_be_destroyed and
one_ref_left, which are not required to be const qualified. The
implementation in fact does require the methods to be const qualified,
because we forgot to add the const_cast inside the decltypes :^)
I realized that we're supposed to float the boxes sideways, but not
always to y=0, so that makes it logical to share the placement logic
with other normal non-replaced blocks.
This is still pretty buggy but we're getting closer. :^)
This is definitely not fully-featured, but basically we now handle
the clear property by forcing the cleared box below the bottom-most
floated box on the relevant side.
The desktop can now be split up into halves (both vertical and
horizontal) and quarters by dragging a window into the corresponding
edge or corner.
This makes tiling behave more like you would expect from similiar
window managers.
For some reason we were not considering the last *two* characters from
the line's ByteBuffer, with the comment next to it talking about \n and
\0. However the buffer doesn't contain a null-byte, so we were
effectively removing the newline and the last character from each
history line!
When create_with_shared_buffer() is called in the next line, the
RefPtr::operator* asserts that the RefPtr is not null. That can happen when
we're low-ish on memory, and the image is huge.
I don't know why basing the available space between floats on the y
coordinate in the middle of each line seemed like a good idea. It just
creates situations with a few pixels of floats overlapping text!
I'm not sure what this was trying to achieve, but it was moving all
line fragments upwards and a lot of things look a lot better if we
just stop doing that.
I had guessed that floating boxes should somehow be hoisted up to the
nearest block ancestor that creates a block formatting context, but
that's just wrong. They move up to the nearest block ancestor like any
other box that's not absolutely (or fixed) positioned. :^)
Boxes can now be floated left or right, which makes text within the
same block formatting context flow around them.
We were creating way too many block formatting contexts. As it turns
out, we don't need one for every new block, but rather there's a set
of rules that determines whether a given block creates a new block
formatting context.
Each BFC keeps track of the floating boxes within it, and IFC's can
then query it to find the available space for line boxes.
There's a huge hack in here where we assume all lines are the exact
line-height. Making this work with vertically non-uniform lines will
require some architectural changes.
We now lazily create an "arguments" array inside functions when code
tries to access it.
This doesn't follow the spec at all but still covers a lot of the
basic uses of arguments, i.e "arguments.length" and "arguments[n]"
Here's a reasonably faithful implementation of ECMAScript 2021 18.2.5.
Some corner cases are not covered, I've left them as FIXME's in the
included unit test.
Also I had to tweak JS::Value::to_i32() to always convert infinity to
zero, which is in accordance with ToInt32 AFAICT.
Previously, the Mixer class would only check for an added BufferQueue
if the list of active queues was empty. If more than one client
connected to AudioServer, its queue would never be added to the list of
active queues.
This fix adds a flag that, when set, will cause the sound thread to wait
for a new BufferQueue.
For many object types we only ever used the regular print_object() in
the js REPL - resulting in a useless "{ }".
This patch adds more individual representations for the following types:
- Boolean/Number/String object: print wrapped value
- ArrayBuffer: print byteLength and hex-formatted bytes in chunks of 16
- TypedArray: print length, byteLength, buffer pointer and values
- Proxy: print target and handler
Also improve the existing pretty-printing output:
- More consistency, most objects now follow the format "[Type] ..."
- Some coloring tweaks
- No two spaces in empty arrays & objects
Possible future improvements:
- Add line breaks between elements of long arrays & objects
Closes#4310.
We were not accounting for space occupied by borders when computing
the vertical (y) position of blocks. This meant that blocks with wide
top/bottom borders could bleed into each other incorrectly.
Fix this by using the combined padding+border geometry instead of just
the padding when placing blocks on the y axis.
We were incorrectly resolving relative length units (ex, em, etc.)
against the containing block in many cases. Fix this to resolve them
against the descendant box we're currently processing.
