I had previously had similar logic in here, but I realized I couldn't
reliably detect if cosmic_text had done any wrapping or not. After a
discussion prompted me to see if recaching was happening while
scrolling, I realized I could at least allow the width to be >= the
measured text size and <= the requested layout width.
This prevents recaching while scrolling.
map_each previously was written such that if a chain of mappings fed
each other, a deadlock could occur because while the first one was
mapped, the second callback gets invoked and tries to update the first
value while it's still being held.
This refactor switches from std Mutex to parking_lot, allowing me to
remove a workaround for needing to run drop callbacks in a separate
thread during the drop of a DynamicGuard.
In addition to that change, the lower level `map_generational` calls now
take a DynamicGuard as their parameter. This allows these functions to
drop ownership of the referenced data during the callback.
The map_each implementation takes advantage of this by ensuring that the
guard is dropped before set is invoked, minimizing potential lock overlaps.
With this refactor, some old code of mine with complex validations now works
again.
When an overlay handle dropped directly after pushing a new overlay, it
was possible for new overlays to be popped off improperly, causing a
subtraction overflow panic later.
This may seem like a lot of options, but here's the reasoning:
- The CSS spec offers four variations: Simplified/Traditional and
Formal/Informal. This spec defines a character set for all for
variations, and it also associates rules for omitting digits in the
informal variants.
- The chinese_number crate does not implement a variant that includes
the tens digit, as required by the cSS spec for the formal variants.
To be able to provide the enumerations that the CSS spec offers *and* to
provide the variations that the chinese_number crate supports, I've aded
8 total list styles for selecting a specific Chinese variation.
Technically nominals supports even more options, but the myriad counting
scale coveres u128::MAX and seems to be the most common counting style.
The previous fix was a fix in contrast_between. However, I then
convinced myself that the selected color was changing when it wasn't
purely because the alpha picker utilizes a checkeboard pattern, and I
was specifically testing grayscale values.
Aka, I was reproducing the "different grays" optical illusion using the
loupe outline color and driving myself crazy trying to figure out what
my code was doing, when in reality it wasn't doing anything.
The real fix? Don't ask for contrast between two similar colors.
OutlineColor and TextColor are both meant to be contrasting colors to
SurfaceColor, which is the background color. The loupe color really
should have switched between any surface-type color and any
foreground-type color, but it instead was asking for two different
foreground colors.
