* Treat doc warnings as errors. Historically we've not done so due to
various `rustdoc` bugs giving false positives but I got it to pass
without failure right now, so perhaps better times have arrived.
* Target only `x86_64-unknown-linux-gnu` on docs.rs as we don't have any
platform specific docs.
* Properly enable example scraping for `xilem`, `xilem_core`, and
`masonry`. Fully disable it for `xilem_web` which does not have examples
as Cargo defines them.
* Pass `--all-features` at docs.rs to match our CI and reduce the
maintenance burden of manually syncing the features list.
* Enable the `doc_auto_cfg` feature for docs.rs which will show a little
tip next to feature gated functionality informing of the crate feature
flag.
* Replaced `[!TIP]` with `💡 Tip` that was inside `<div
class="rustdoc-hidden" />`. The GitHub specific tip causes a `rustdoc`
error and [didn't even render
properly](ac2ca38785/masonry/src/doc/01_creating_app.md).
* Updated `01_creating_app.md` just enough to get `rustdoc` to pass, but
that file needs a bunch of more work, as it is outdated.
This is very useful for debugging performance issues. I've already used
it to debug [#masonry>`to_do_list`: Horrendous
performance](https://xi.zulipchat.com/#narrow/stream/317477-masonry/topic/to_do_list.3A.20Horrendous.20performance).
Setting a feature works on a workspace-wide basis. I.e `cargo run
--example mason --features tracy` works.
Some weirdness:
- Tracy seems to assume we know when a frame will "start", but we only
know if we'll repaint once processing for an event has finished.
- Something seems to be starting a default "Frame", which isn't really
right. We don't have any continuous frames. Maybe we should always
request a redraw if tracy is enabled.
Either way, I think this feature is useful to land *now*, so am not
planning on resolving these in this PR unless someone provides a
solution.
- Adds tracing_android_trace
- Correct the span for VariableLabel
- Make the created apps "debuggable"
- Enable spans for `wgpu`'s `profiling` results
- Add a span around the Vello rendering to show when that is
This adds a new `VariableLabel` widget, which animates its weight to a
target value in a linear fashion (over a fixed time period). Also adds
support for this in Xilem, and a new `variable_clock` example. This
example also runs on Android.
[Screencast_20240812_171138.webm](https://github.com/user-attachments/assets/5df623f9-f4ca-4b55-b6a9-2047d2581b56)
Current status: The code in Xilem and Masonry library crates is final.
I'm planning on significantly updating the actual example.
Outstanding issues:
- [X] Hacks in support for "Roboto Flex", by always loading it from the
local file - resolved
- [X] It's not clear what subset of Roboto Flex we should use - still
open to bikeshedding
- [ ] The variable font animation support is not really as generic as it
should be. This starts to drift quite close to a styling question,
however.
- [ ] The only supported variable axis is `wgth`
Rather than have to keep a dependency on `kurbo` at the correct version,
always use it via `vello`.
This makes this match how `peniko` is already used within `masonry`.
See also linebender/vello#439
This should open the door to doing much more comprehensive testing at
higher level in the nearish future (including e.g. in `xilem_masonry`)
There is one "semi-false-positive" lint triggered, which I have fixed.
Otherwise, the required
```
cargo upgrade --ignore-rust-version
cargo update
```
This:
1) Renames the current/old `xilem_core` to `xilem_web_core` and moves it
to the `xilem_web/xilem_web_core` folder
2) Creates a new `xilem_core`, which does not use (non-tuple) macros and
instead contains a `View` trait which is generic over the `Context` type
3) Ports `xilem` to this `xilem_core`, but with some functionality
missing (namely a few of the extra views; I expect these to
straightforward to port)
4) Ports the `mason` and `mason_android` examples to this new `xilem`,
with less functionality.
This continues ideas first explored in #235
The advantages of this new View trait are:
1) Improved support for ad-hoc views, such as views with additional
attributes.
This will be very useful for layout algorithms, and will also enable
native *good* multi-window (and potentially menus?)
2) A lack of macros, to better enable using go-to-definition and other
IDE features on the traits
Possible disadvantages:
1) There are a few more traits to enable the flexibility
2) It can be less clear what `Self::Element::Mut` is in the `rebuild`
function, because of how the resolution works
3) When implementing `View`, you need to specify the context (i.e.
`impl<State, Action> View<State, Action, [new] ViewCtx> for
Button<State, Action>`.
---------
Co-authored-by: Philipp Mildenberger <philipp@mildenberger.me>
Recently, `instant` has been marked as unmaintained by the maintainer. A
suggested replacement is `web-time`, which is used by `winit` and is
already in our dependency tree.
This removes a class of dependencies from within both `masonry` and
`xilem` on the `winit` crate where we can just use `dpi` directly
instead.
The `dpi` crate is meant (like `cursor_icon`) to be a shared ecosystem
crate rather than only for usage with `winit`.
`cursor_icon` is a crate that is used by `winit` to provide its
`CursorIcon` type separately from the `winit` crate.
This re-exports the `CursorIcon` from `masonry` and then uses that
rather than via `winit:🪟:CursorIcon`, allowing the use of the
`CursorIcon` without having to independently discover its provenance.
This is also one step towards not requiring `winit` within the `masonry`
internals apart from the actual window / event loop management.
Kaur Kuut