This used to be needed by Core::ProcessStatisticsReader, but since we no
longer use that for the CPU graph, we can just lose it (along with a
FIXME about it.)
This fixes#10940.
Previously, all presses of the Delete key without a modifier in Browser
were uselessly consumed by the "Delete" action in the bookmark context
menu.
This wasn't particularly difficult, and there's not much use for the
nicer interface yet either. While unveil() is of limited use in js(1)
as it should be able to open arbitrary files, I feel like we should be
able to add a pledge() call.
Almost all synthesizer code in Piano is removed in favor of the LibDSP
reimplementation.
This causes some issues that mainly have to do with the way Piano
currently handles talking to LibDSP. Additionally, the sampler is gone
for now and will be reintroduced with future work.
For the upcoming synthesizer, having an abstracted ADSR envelope concept
is highly desirable. Additionally, Envelope is mostly constexpr and
therefore super fast :^)
This makes the default image fit perfectly into the default viewport,
which means the first fit_image_to_view call will end up with a scale of
exactly 1. This scale level has no visual artifacts, which is the more
intuitive 'default' behavior.
Fixes#10975.
This simplifies a bunch of error handling and makes the main function
quite a bit shorter.
It will become shorter yet, as we get better at propagating errors. :^)
This is a first port of a simple program to LibMain. A bunch of code is
immediately simplified thanks to the LibSystem wrappers and ability to
use TRY(). This is pretty cool!
This creates an error that contains the name of the syscall that failed.
This allows error handlers to print out the name of the call if they
want to. :^)
By linking with LibMain, your program no longer needs to provide main().
Instead, execution begins in this function:
ErrorOr<int> serenity_main(Main::Arguments);
This allows programs that link with LibMain to use TRY() already in
their entry function, without having to do manual ErrorOr unwrapping.
This is very experimental, but it seems like a nice idea so let's try it
out. :^)
This is a hack to avoid a circular dependency issue with the stack check
failure handler being in LibC.
This is not ideal, and there's most likely a better way to solve this.
That said, LibSystem should not have anything but thin wrappers around
system calls, so stack protectors have limited utility here anyway.