This commit adds a draw_physical_line method, which is the exact same
as draw_line, except it's parameters are already transformed and
scaled. This is used by both draw_line and draw_rect, as a slight
optimization to save some work. It also fixed draw_rect not checking
whether it should draw the lines before drawing them.
This allows the painter to be scaled separately in both directions, and
not just in integer intervals. This is crucial for proper SVG viewBox
support.
Most bitmap-related things verify the scale to be one as of now.
This commit unifies methods and method/param names between the above
classes, as well as adds [[nodiscard]] and ALWAYS_INLINE where
appropriate. It also renamed the various move_by methods to
translate_by, as that more closely matches the transformation
terminology.
This adds a *very* simplified version of the UNICODE BIDIRECTIONAL
ALGORITHM (https://www.unicode.org/reports/tr9/), that can render most
bidirectional text but also produces awkward results in a large amount
of edge cases, and as such, this should probably be replaced with a
fully spec compliant implementation at some point.
We had some inconsistencies before:
- Sometimes "The", sometimes "the"
- Sometimes trailing ".", sometimes no trailing "."
I picked the most common one (lowecase "the", trailing ".") and applied
it to all copyright headers.
By using the exact same string everywhere we can ensure nothing gets
missed during a global search (and replace), and that these
inconsistencies are not spread any further (as copyright headers are
commonly copied to new files).
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
Problem:
- `constexpr` functions are additionally decorated with `inline`
keyword. This is redundant since `constexpr` implies `inline`.
Solution:
- Remove redundancies.
This uses the per glyph width to determine if the glyph is actually
present in the font, and not just inside the range the font can covers
This means that characters that are in the font's range but that are
missing a glyph will show up as the missing character glyph instead of
being invisible.
This replaces the glyph width spinbox in the font editor with a
checkbox when editing fixed width fonts that indicates if the
currently selected character's glyph is present in the edited font
(For variable width fonts a non zero width implies presence)
This commit also changes the background color of glyphs in the glyph
map based on the presence of each specific glyph in the font.
Since we were always saving the glyph widths array to the font file, we
now also always load it, even on (which also simplifies the logic a bit)
fixed width fonts. We also set it initially to 0 instead of the default
fixed width, which allows us to use it to check for glyph presence in
both fixed width and variable width fonts.
This warning informs of float-to-double conversions. The best solution
seems to be to do math *either* in 32-bit *or* in 64-bit, and only to
cross over when absolutely necessary.
Since we first check the winding number and only then update it, fills
for "Rectangle-like" (made up of 2 parallel segments) paths would draw
nothing when filled by NonZero winding rules. (Fix by alimpfard)
I hereby declare these to be full nouns that we don't split,
neither by space, nor by underscore:
- Breadcrumbbar
- Coolbar
- Menubar
- Progressbar
- Scrollbar
- Statusbar
- Taskbar
- Toolbar
This patch makes everything consistent by replacing every other variant
of these with the proper one. :^)
This commit makes the user-facing StdLibExtras templates and utilities
arguably more nice-looking by removing the need to reach into the
wrapper structs generated by them to get the value/type needed.
The C++ standard library had to invent `_v` and `_t` variants (likely
because of backwards compat), but we don't need to cater to any codebase
except our own, so might as well have good things for free. :^)
A "Tray" is a sunken container area for widgets. The first intended
client of this style is the GUI::FilePicker's common locations frame.
Thanks to @nvella for coming up with the term "Tray" :^)
