It's possible for the module to request too many locals, we now reject
such modules instead of trying to allocate space for them.
The value itself is chosen arbitrarily, so future tweaks _might_ be
necessary.
Found by OSS-Fuzz: https://oss-fuzz.com/testcase?key=4755809098661888
They're mostly used in literal random data, so it isn't like
there is a high demand for it, but it's cool to have more complete
implementation anyway. :^)
This improves the look of tabs and their focus rects. In particular, the
concept of a "text rect" is removed, and whatever tab content area is
left over after the icon and close button are added is used as the area
to draw the text into. This approach is simpler than having a separate
text rect.
This is the first step in transitioning Piano to a full LibDSP backend.
For now, the delay effect is replaced with a (mostly identical)
implementation in LibDSP.
The new ProcessorParameterSlider attaches to a LibDSP::Processor's
range parameter (LibDSP::ProcessorRangeParameter) and changes it
automatically. It also has the ability to update an external GUI::Label.
This is used for the three delay parameters and it will become useful
for auto-generating UI for Processors.
As Piano will later move to the RollNote defintions of LibDSP, it's a
good idea to already insert velocity and pitch support, even though it's
currently not used.
Test files were getting analyzed twice, which the tool does
not like, and causes it to exit with a fatal error.
Also make the workflow run in PRs anytime the file is edited,
so that we can get immediate feedback without waiting till the
next day.
Shades are colors darker than the color, tints are colors lighter.
This is helpful in places where we need a bunch of similar colors
with some small differences.
Some pixels weren't fully transparent in the top-right corner, which
was pretty visible on file selection in File Manager on default theme.
The files has been also compressed using the Zopfli algorithm, since
they would have been rewritten here anyway.
The common thin-cap button look (1px highlight, 2px shadow) looks nice
on regular buttons, but the scrollbar didn't feel quite right.
This patch adds 1px of offset to the highlight, giving it a thick-cap
look (which I have named Gfx::ButtonStyle::ThickCap) :^)
The default action (shown in bold) indicates what would you get
by double-clicking on file. Since it's a default option, I think it
deserves to be on top (together with alternative launch options). :^)
Also they're not task actions like "Extract .zip here" or "Add to
bookmarks".
Some i64 values will not fit in normal doubles, and these values _are_
tested by the test suite, this makes the test runtime capable of
handling them correctly.
Previous implementation sometimes didn't release the key after pressing
and holding shift due to repeating key updates when holding keys. This
meant repeating updates would set/unset `m_both_shift_keys_pressed`
repeatedly, sometimes resulting in shift still being considered pressed
even after you released it.
Simplify left and right shift key pressed logic by tracking both key
states separately and always updating modifiers based on them.
