Similar to commit bcfa4a3, this enables navigating to a file:// URL in
Ladybird with audio file extensions.
The file extensions used here were taken from
https://docs.fileformat.com/audio/ (except QOA, which isn't listed).
This commit changes the variables used to represent the size and
progress of downloads from u32 to u64. This allows `pro` and
`Browser` to report the total size and progress of a download
correctly for downloads larger than 4GiB.
Calling `from_utf8` with a DeprecatedString will hide the fact that we
have a DeprecatedString, while using `from_deprecated_string` with a
StringView will silently and needlessly allocate a DeprecatedString,
so let's forbid that.
When called with `SearchInPath::Yes`, calls to `Core::System::exec()`
would fail. The value returned from
`resolve_executable_from_environment()` was assigned to a StringView,
but the original reference was not kept, causing the StringView to
appear empty.
Finally, the end of our journey to fallible I/O!
Now all that's left to do is to rewrite the code around each and every
.release_value_but_fixme_should_propagate_errors() call. :^)
Closes#17129.
DeprecatedFile doesn't properly handle I/O or OOM errors, and only
provides a rudimentary interface to reasonably handle it. We have long
since learned how to do it "properly" with ErrorOr<> and similar
interfaces. See also d43a7eae54.
Note that this leaves behind an invocation to DeprecatedFile in
Ladybird/AndroidPlatform.cpp. However, that part of the system has
compilation errors since at least January, and will get removed or
rewritten as part of issue #19085. Let's not wait for this Android port
to remove this deprecated API.
The if statement for setting the O_NONBLOCK flag was written the other
way around, causing Core::File to open files in non-blocking mode, when
we didn't actually specify it.
Some applications may not want to have the ability to create a
file if it doesn't exist, but still be able to read and write
from it. The easy solution here would be just to not apply
O_CREAT when creating the flags, but to prevent breaking a ton
of applications, having a `DontCreate` mode is the best for now.
`Core::System::fstatat()` is similar to our standard `Core::System`
wrappers.
`Core::Directory::stat(relative_path, flags)` is a convenience method if
you already have a Directory, to stat a file relative to it.
This closely mirrors Socket::set_blocking. Note that it does not make
sense to make this a virtual method on a base class, since
SeekableStream and FixedMemoryStream cannot possible be anything except
than blocking.
That's what this class really is; in fact that's what the first line of
the comment says it is.
This commit does not rename the main files, since those will contain
other time-related classes in a little bit.
This gives us free error-propagation in Core::command(...) and
HackStudio::ProjectBuilder::for_each_library_dependencies.
The comment about "String will be in the null state" has been misleading
for a long time, so it is removed.
These 2 are an actual separate types of syscalls, so let's stop using
special flags for bind mounting or re-mounting and instead let userspace
calling directly for this kind of actions.
It's unnecessary to allocate a string when we only want to compare it
with another string.
This change also adds a helper for string literals, so that we won't
need to add -sv suffix everywhere. :^)
This class, in a similar fashion to what has been done with
`InputBufferedStream`, postpones write to the stream until an internal
buffer is full.
This patch also adds the `OutputBufferedFile` alias.
This shouldn't have been moved to EventLoopManager, as the manager is
global and one-per-process, and the implementation is one-per-loop.
This makes cross-thread event posting work again, and unbreaks
SoundPlayer (and probably other things as well.)
Things such as timers and notifiers aren't specific to one instance of
Core::EventLoop, so let's not tie them down to EventLoopImplementation.
Instead, move those APIs + signals & a few other things to a new
EventLoopManager interface. EventLoopManager also knows how to create a
new EventLoopImplementation object.
Using QEventLoop works for everything but it breaks *one* little feature
that we care about: automatically quitting the app when all windows have
been closed.
That only works if you drive the outermost main event loop with a
QCoreApplication instead of a QEventLoop. This is unfortunate, as it
complicates our API a little bit, but I'm sure we can think of a way to
make this nicer someday.
In order for QCoreApplication::exec() to process our own
ThreadEventQueue, we now have a zero-timer that we kick whenever new
events are posted to the thread queue.
The EventLoop is now a wrapper around an EventLoopImplementation.
Our old EventLoop code has moved into EventLoopImplementationUnix and
continues to work as before.
The main difference is that all the separate thread_local variables have
been collected into a file-local ThreadData data structure.
The goal here is to allow running Core::EventLoop with a totally
different backend, such as Qt for Ladybird.
