Previously, if you used one of the keyboard shortcuts to select a
different tool, it didn't change the cursor to the corresponding
one till you clicked somewhere / did something else to trigger an
update. This was pretty jarring since there's no indication as to
whether the tool change was successful or not.
This patch just calls `set_override_cursor()` when a valid active
tool is set to immediately update it.
This is a combination of the efforts of multiple people and hours of
pain trying to configure VSCode properly. This should give a good
baseline for anyone trying to develop Serenity with VSCode.
Co-authored-by: Hendiadyoin1 <leon2002.la@gmail.com>
In general, I think `opt == x` looks much nicer than
`opt.has_value() && opt.value() == x`, so I'm updating
the remaining few instances I could find with some regex
magic in my search.
On my machine (c), /mnt/c/Windows/System32 is not on the PATH by
default. This causes reg.exe to fail, which is responsible for detecting
the presence of QEMU. By putting this path on the PATH on WSL, it will
always work regardless of the specific PATH configuration, and QEMU is
always detected.
The new asctl (audio server control) utility expands on avol with a
completely new command line interface (documented in the man page) that
supports retrieving and setting all exposed audio server settings, like
volume and sample rate. This is currently the only user-facing way of
changing the sample rate.
1) The Sound Player visualizer couldn't deal with small sample buffers,
which occur on low sample rates. Now, it simply doesn't update its
buffer, meaning the display is broken on low sample rates. I'm not too
familiar with the visualizer to figure out a proper fix for now, but
this mitigates the issue (and "normal" sample rates still work).
2) Piano wouldn't buffer enough samples for small sample rates, so the
sample count per buffer is now increased to 2^12, introducing minor
amounts of (acceptable) lag.
All audio applications (aplay, Piano, Sound Player) respect the ability
of the system to have theoretically any sample rate. Therefore, they
resample their own audio into the system sample rate.
LibAudio previously had its loaders resample their own audio, even
though they expose their sample rate. This is now changed. The loaders
output audio data in their file's sample rate, which the user has to
query and resample appropriately. Resampling code from Buffer, WavLoader
and FlacLoader is removed.
Note that these applications only check the sample rate at startup,
which is reasonable (the user has to restart applications when changing
the sample rate). Fully dynamic adaptation could both lead to errors and
will require another IPC interface. This seems to be enough for now.
Two new ioctl requests are used to get and set the sample rate of the
sound card. The SB16 device keeps track of the sample rate separately,
because I don't want to figure out how to read the sample rate from the
device; it's easier that way.
The soundcard write doesn't set the sample rate to 44100 Hz every time
anymore, as we want to change it externally.
This AO is required for a bunch of PlainTime related methods.
As part of this change the `TemporalTime` record was renamed to
`UnregulatedTemporalTime` and a new `TemporalTime` record that matches
the other Temporal parse result records was added. This also has the
added benefit of getting rid of a would be round-trip cast from integer
to double and back in `ParseTemporalTimeString`.
This commit is preemptive to upcoming commits which add more subtags to
the CLDR generator. Rather than generating a giant HashMap containing
all data, generate more (smaller) Array-based tables. This mimics the
UCD generator. This also allows simpler lookups at runtime since we can
generate index-based lookups into the smaller tables rather easily.
Without this change, adding the remaining locale subtags would result
in the generation and compilation of UnicodeLocale.cpp taking about 30s
on my machine. With this change, it takes about half that. Additionally,
the size of the generated file reduces by about 1.5MB.
The UCD set of data contained a very small subset of all locales just to
handle some special casing rules. This enumeration will be needed within
the CLDR generator as well. So rather than duplicate the enum, remove it
from the UCD generator in favor of the full list of locales known by the
CLDR generator.
We were only notifying clients about the change, but didn't actually
update the internal cache in ConfigServer itself.
Thanks to "The Grey One" for pointing this out. :^)
This application was including, opening and unveiling the path for
a config file, however it never actually reads or saves anything
from the configuration file.
Since it's easy enough to add it back later if needed, probably
makes sense to remove the unused code right now?
There was a lot of error handling here previously when writing to
a config file failed, but this was removed since we have no way of
conveying a `Config::write` failure from the ConfigServer.
