Previously we would loop over all glyphs in the GlyphMap, compute
their rects, and then test to see if the mouse click position was
inside that rect. This is silly since each element in the glyph
map for a particular font is the same size, and we can just do
some coordinate manipulation to get the index directly.
We can now drag-and-drop files onto PixelPaint to be able to open
them. Each dropped file opens in a separate editor (which is the
default behavior of Photoshop).
Previously, all the UI setup was done in `main.cpp`, with a whole
bunch of lambdas,, and actions etc just being stored in the main
function. This is probably an artifact from back when it was first
created.
Most other applications now have a "MainWidget" class of some sort
which handles setting up all the UI/menubars, etc. More importantly,,
it also lets us handle application-wide events which we were
previously not able to do directly, since the main widget was just
a default GUI::Widget.
This patch moves all the core functionality of the PixelPaint
application into PixelPaint::MainWidget, which is then instantiated
by the main function. There is likely some more refactoring that
would help, but this commit is big enough as it is doing mostly
a direct port.
These are tested by test262 but the current test262-runner reads the
files in python which automatically converts \r\n to \n.
This meant that we passed the tests while we should not have.
The current implementation felt a bit ad-hoc and notably allowed
textContent to operate on all node types. It also only returned the
child text content of the Node instead of the descendant text content.
This expands the reach of error propagation greatly throughout the
kernel. Sadly, it also exposes the fact that we're allocating (and
doing other fallible things) in constructors all over the place.
This patch doesn't attempt to address that of course. That's work for
our future selves.
In 553361d we started mprotecting the atexit handlers when they are not
being modified or executed. As part of that commit, we unintentionally
changed the max number of global destructors from 1024 to 256 (on x86,
only 128 on x86_64). This patch expands the initial size of the global
destructors page to 2 pages from 1, and allows the pool to be expanded
at runtime by mapping a new set of pages and copying the AtExitEntries
over.
...by replacing it with a ctor that takes the buffer instead, and
handling the allocation failure in ArrayBuffer::create(size_t) by
throwing a RangeError as specified by the spec.
Instead of having a single limit here, which we had to increase once to
work with ASAN enabled, check whether HAS_ADDRESS_SANITIZER is defined
and use 32 KiB, and 16 KiB otherwise (which is what we used previously).
This idea is shamelessly stolen from V8:
https://github.com/v8/v8/blob/b2b44af/src/execution/isolate.cc#L1381-L1387
Executing 100 times vs 10 times doesn't increase test coverage
substantial, this API is stable and more iterations is just a
waste of time.
Without KVM this test is a clear outlier in runtime during CI:
```
START LibC/TestQsort (106/172)
PASS LibC/TestQsort (41.233692s)
```
The default template argument is only used in one place, and it
looks like it was probably just an oversight. The rest of the Kernel
code all uses u8 as the type. So lets make that the default and remove
the unused template argument, as there doesn't seem to be a reason to
allow the size to be customizable.
I broke this when I made the protocol objects be wrapped by smart
pointers to appease static analysis.
The Protocol base class currently VERIFY's that it's never called.
So to have the best of both worlds until someone actually fixes
the code to do proper de-registration, just call `exit(..)` so the
smart pointers never go out of scope.
This type is useful, as the sizes will be visible in the compiler error
messages, as they will be part of the template parameters. This is not
possible with a normal static_assert of the sizeof a type.
