This required overriding the main theme file to position it where I
wanted it to be. head.hbs puts it above the button bar, and header.hbs
puts it outside the page area entirely.
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.
