During the change callback process, unlocked is called to allow the
change callbacks to run while the dynamic is unlocked. The error with
the previous version of this code is that the during_callback_state was
always overwritten when being returned. The problem is that another
thread could currently have the mutex locked and could have stored its
own state -- which can happen if two threads are both trying to invoke
change callbacks at the same time.
By moving the state saving and reloading to only happen when the mutex
guard is acquired, we can ensure that interleaving threads will work
correctly.
Refs #153
This turned out to be "needed" by the debug window due to how dynamic
locking was nested when a for_each call was being invoked. To keep the
code simple, for_each_subsequent was added.
I'm not sure exactly what caused this that other simpler cases were not,
but essentially nodes were already removed once by the time this loop is
evaluated, so we can skip adding them back to the list again.
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.
I originally removed this API to ensure no Cushy widgets were using
winit directly, but I've reintroduced it so that third party widgets can
still interact with winit if needed.
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.
Closes#138
This implementation works around most of the locking issues that arose
the first few times I tried fixing this. Unfortunately it's been just
long enough for me to forget how I triggered some catastrophic issues in
the past, but all of the current examples that would invoke this
behavior continue to work, and some of the side projects that have some
weird usages also still work.
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.
`generate_error` can technically fail to generate a contrasting color if
the primary color is desaturated too much. This is beacuse we never
increase the saturation.
This change makes the color scheme builder stop one iteration shy of a
full circle.
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.
I had forgotten why I had `self::image::Image` and it was causing the
docs to show up out of order. This now makes them all consisent, fixing
the docs issue.
This was a holdover while I was still implementing the PlatformWindow
interface. Cushy widgets shouldn't be able to access winit directly,
otherwise they could cause unwanted effects when not running in a
standalone Cushy app but rather embedded in a game.
Currently passing the entire input area because it's easy. Not closing
the issue because the correct thing to do would be to constrain the
location to a smaller area on the current line (or the current line).
Refs #122
While working on the changelog, I realized I didn't provide a type that
allowed a third party developer to provide a
PlatformWindowImplementation. This type now completes it.
This commit adds my first take at creating a harness for a user's guide
using the new capture functionality. The example has tests that ensure
the align widget creates the expected results.
Somehow I missed that my changes for weak callbacks broke the theme
editor. I thought I had it working with the try_get changes, but I
discovered several flaws in this approach.
In the end, ownership has been transferred to the CallbackHandle, and a
CallbackHandle can relinquish its reference to create weak graphs. This
is how weak_clone now works.
This ensures frames render consistently.
This change only affects the animation recorder. The regular virtual
recorder interface blocks when refresh is called.
Closes#98
This finishes my initial refactoring of the dynamic system to add
support for several dataflows including:
- Pure data sources that can be implemented using an `Owned<T>` at the
root of a graph of `Dynamic<U>`/`DynamicReader<U>`s.
- Read-only data sinks. I thought this would be more useful across other
widgets, but in general, Progress and Label seem like the only types
that this applies to currently.
- The ability to mix/match Dynamic/DynamicReader in tuple-based
for_each/map_each.
For some reason I forgot about 1.0 being an edge case, but I also didn't
think about negatives either. Applying a clamp is the right move here.
Refs #120
Refs #98
This refactor overhauls the reactive system to move all the reactive
methods to traits. The side effect of this change is that now
DynamicReader's API is the same as Dynamic's API, but because it only
implements Source<T>, DynamicReader does not offer any mutation
functions.
While it's unfortunate to have more traits to include to use Cushy, this
seems like the best option, and it offers a path to try to integrate
this into the tuple ForEach/MapEach traits. Unfortunately, my attempt at
doing those in this set of changes led to issues specifying generic
associated lifetimes for the DynamicGuard. But, I was also in the middle
of this larger refactoring, so it might be that a fresh attempt will
succeed.
After adding weak_clone, I realized that all map functions should use
weak references anyways. In the process of implementing this, I ran
tests a lot and found other edge cases where I hadn't properly reasoned
about Drop behavior.
While some of the state cleanup is a bit overkill at the moment, this is
in anticipation of wanting a WeakDynamicReader-like type.
The animation doctest randomly failed on me this morning, and I isolated
it to the order of the two mutexes. There's no reason to hold the
deadlock mutex for more than the check for deadlock, so I switched which
mutex the condvar is synchronizing using to ensure that another thread
couldn't cause a deadlock by dropping a DynamicMutexGuard while the
block_until_updated thread is performing its state check.
There was a small window between when notify_all and the strong count
for the Arc is decreased that a DynamicReader could observe the strong
count still being greater than the reader count, but the drop thread
just hasn't proceeded far enough.
Now the on_disconnect is stored in an option, and its presence denotes
that the disconnect logic has not fired yet. DynamicReader now checks
on_disconnect in addition to the strong count.
This cascaded into a lot more work than expected. However, in general,
if one clones a `WidgetInstance` and shares it between two windows, it
should now work. Widget authors must ensure that when they cache
information, they do so with either a `WidgetCacheKey` or use a
`WindowLocal<T>` if per-window state is desired.
This is demonstrated in the debug-window example, where the counter of
open windows is next to a clone of the same button from the main window
that opens a new window.
While this was a workaround for a docs.rs issue (Px/Lp are not
linked), I decided having the shorter import path would look better in
the examples.
It probably wasn't necessary to update all of the references in the
internal code, but I decided it was worth the consistency.
Closes#112
This removes the last manual byte change I can find. While what the user
reported was that this was causing incorrect selection, using the arrow
keys when in this situation could lead to a panic, because the offset
was not a valid character offset.
Closes#91
There's some details to still figure out, which are in new issues:
- #109: When opening a window, no handle is returned that gives access to the
window from the opener. Technically this can all be wired up manually,
with exception of requeesting the window close.
- #107: How can a window close itself? Once we have a handle type, we still
need a mechanism to allow a button on a window request that the window
closes gracefully. The examples that currently close the window
call exit instad.
This sounds like a regression, but it was masking a "race condition".
DynamicGuard runs the change callbacks on drop in a background thread.
Validations was using the guard to not have to lock twice.
This led to an issue where the invalid count might be non-zero due to
the callbacks not being invoked, preventing the closure from being
invoked even though there are no validation errors.
Introducing compare_swap gives a higher-level API for Validations to
use, and it also ensures the callbacks are able to be run in the current
thread.
The Container code was causing small rounding errors when laying out
that would cause the layout to sometimes me larger by a pixel. I
searched for all locations we are applying padding and added rounding
calls.
Refs #92
This adds upon the work in #94 by allowing the dynamic's value to be set
and it cause the window size to change.
I've ordered the resizing operations so that changes to the property are
prioritized over automatic adjustments. This doesn't change the behavior
for automatic adjustments in any way.
Closes#97
There was a potential race condition described in #97 that I realized I
had seen occasionally when interacting with an element that was
currently being animated. These were in complex situations, so I thought
I had a situation that could have legitimately caused the warning.
However, this warning is preventing a very specific coding "error", and
that program did not have it. The existing implementation would
potentially prevent one thread's change from invoking its callbacks
because another thread was already executing its callbacks.
This change moves that state into a Mutex/Condvar pair that allows
detecting reentry while allowing other threads to block until its their
turn. When it becomes their turn, they can check whether the callbacks
were invoked with the current value or not to prevent callbacks from
being invoked in quick succeession with the same value by multiple
threads.
Realized that I was skipping invisible glyphs during construction of
MeasuredText. Once those were in, most of the issues vanished. A few
small tweaks and now it works surprisingly well.
- Blur no longer expands the shadow geometry, but instead is clamped to
avoid overlapping drawing calls.
- Overlay now handles hit tests correctly with regards to the original
relative widget.
- Align was using an Into conversion that wasn't actually correct,
causing the contents to not actually get aligned in some situations.
Rather than clip or cause shadows to be weirdly shaped, the shape is
adjusted if the blur radius is too large for the given geometry. This
ensures the shadows always draw correctly, but it also forces shadows to
render their full blur + spread gradients.
