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.
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#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.
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.
Installing a callback now returns a CallbackHandle. All map-style APIs
install this handle automatically on the created dynamic, which keeps
the callback installed until the dynamic is freed. All other APIs
return the handle for the caller to either call persist() or store
somewhere.
Now, the dynamic system can be used for application-long data with
almost no fear of leaking data due to how callbacks are being installed.
Technically cycles are still possible by moving clones into the
callbacks, so a WeakDynamic type might be worth exposing.
Closes#60
Stepping in sliders is a compromise due to the flexibility of the
current slider implementation. I don't want to force types to implement
Add, and I don't like forcing types to require a Step (ie, what's the
appropriate value for f32 to specify as its next value?). Using a
percentage combined with lerp keeps the implementation fairly
straightfoward, although I remember experiencing this type of
configuration in another UI framework a long time ago and thinking it
was a little annoying to work with.
Ultimately, setting actual step boundaries can be done by customizing
the type that the slider is operating over. I feel like that's a much
more powerful design than I've experienced in previous frameworks, so
I'm hoping this percent step behavior is a reasonable compromise.
Inset outlines may not be the right approach, but it simplifies
potential alignment issues caused by insetting all filled background
drawing by half the width of the focus ring.
