This example is inspired by:
https://troz.net/post/2024/swiftui-mac-2024/
Current status:
- Lists status code
- Can select status code
- Downloads image from status code
- Shows image from status code
This adds two new features to Xilem:
- The worker view, which is the obvious extension to `task` for multiple
operations
- The `image` view, which just uses Masonry `Image`.
It also fixes a the Masonry Image view's layout to use the already
extant but unused method.
- 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`)
This is the `rerun_on_change` view described in #440, I named it
`MemoizedAwait` as I think that fits its functionality.
It got also additional features `debounce_ms` (default `0`) and
`reset_debounce_on_update` (default `true`) as I think that's quite
useful, in case a lot of updates are happening.
When `reset_debounce_on_update == false`, `debounce` is more a throttle
than an actual debounce.
This also adds a more heavily modified version of the example added in
#427, also showing `OneOf` in xilem_web (which didn't have an example
yet).
This *could* be considered as alternative to #440 (at the very least the
example) but those approaches could also well live next to each other.
---------
Co-authored-by: Markus Kohlhase <markus.kohlhase@slowtec.de>
There is one "semi-false-positive" lint triggered, which I have fixed.
Otherwise, the required
```
cargo upgrade --ignore-rust-version
cargo update
```
Supercedes https://github.com/linebender/xilem/pull/411
This is designed with #417 in mind, to not lock-in to our event loop.
---------
Co-authored-by: Philipp Mildenberger <philipp@mildenberger.me>
I have intentionally left out the `xilem_core::adapt` variant here in
order to have a clear classic Elm example. I would rather show the
`adapt` variant in a separate example.
This ports xilem_web to the new xilem_core.
There's also a lot of cleanup internally:
* Get rid of all of the complex macros to support DOM interfaces, and
instead use associated type bounds on the `View::Element`.
* Introduce an extendable modifier based system, which should also work
on top of memoization (`Arc`, `Memoize`) and `OneOf` views with an
intersection of the modifiable properties.
* This modifier based system gets rid of the hacky way to propagate
attributes to elements, and takes inspiration by masonrys `WidgetMut`
type to apply changes.
* Currently that means `Attributes`, `Classes` and `Styles` to reflect
what xilem_web previously offered.
Downsides (currently, needs some investigation):
~~Due to more internal type complexity via associated types this suffers
from https://github.com/rust-lang/rust/issues/105900. The new trait
solver should hopefully mitigate some of that, but it seems currently it
completely stalls in the todomvc example (not in other examples).~~
~~The deep, possibly completely static composition via associated
type-bounds of the view and element tree unfortunately can take some
time to compile, this gets (already) obvious in the todomvc example. The
other examples don't seem to suffer that bad yet from that issue,
probably because they're quite simple.~~
~~I really hope we can mitigate this mostly, because I think this is the
idiomatic (and more correct) way to implement what the previous API has
offered.~~
One idea is to add a `Box<dyn AnyViewSequence>`, as every element takes
a "type-erased" `ViewSequence` as parameter, so this may solve most of
the issues (at the slight cost of dynamic dispatch/allocations).
Edit: idea was mostly successful, see comment right below.
I think it also closes#274
It's a draft, as there's a lot of changes in xilem_core that should be
upstreamed (and cleaned up) via separate PRs and I would like to
(mostly) fix the slow-compile time issue.
---------
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
Since we're suffering from the orphan rule with the new xilem_core
implementation, we cannot use `View` in downstream crates for external
types such as a `WidgetView` implementation for `&'static str` in Xilem.
This PR adds an `OrphanView` trait which the `Context` of the `View` has
to implement for the type which has an implementation in xilem_core for
this. The `View` impl for these types is basically a proxy for
`OrphanView` (which in turn has the same method signature as `View`), so
downstream crates can achieve the same as with the `View`.
---------
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
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>
This bumps the `accesskit_consumer` version in `Cargo.lock` to the next
minor version (`0.19.1`).
That version includes better error messages when AccessKit panics.
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.
These are the results of running
```sh
cargo upgrade --ignore-rust-version
cargo update
```
in preparation for the upcoming release.
These are semver compatible updates.
The `image` crate has a number of dependencies which aren't needed in
the core masonry crate, so we can turn off the default image format
support and only enable "png" when used as a dev dependency.
Also, make it a workspace dependency at the same time so that the
version is only stated in a single location.
Add AccessKit dependency.
Add accesskit_winit dependency.
Add methods to the Widget trait which create the accessibility tree and
react to accessibility events.
* Rename classic `xilem` to `xilem_classic` and the new `xilem_masonry`
to `xilem`.
No directory structure changes yet to avoid merge conflicts before
RustNL.
* Base common dependencies on workspace dependencies.
* Bump `masonry` version to `0.2.0`.
* Remove some legacy docs.rs configuration inherited from Druid/Glazier
that is no longer needed.
* Unify ordering of properties.
This brings in a lot of the old work from Druid and Masonry (prior to
linebender/masonry#56) on text, as well as some types from Glazier.
Needed work:
- [X] Text display using abstract types
- [x] Text selection with mouse
- [x] Text input with keyboard
- [ ] IME integration (of the kind winit understands)
Follow up work:
- [ ] Keyboard control of the selection area (hard-coded hotkeys)
- [ ] [Proper
placement](https://raphlinus.github.io/text/2020/10/26/text-layout.html#shaping-cluster)
of cursor
- [ ] Input methods
- [ ] Proper hotkey handling
- [ ] Copy and/or paste
* Create a minimal xilem_masonry
* Add a first draft of view sequences
* Implement a flex view
* Fix clippy
Some of these suggestions are kind of bad
but that's by-the-by
* Update CI to 1.77
* Skip masonry docs in CI
* Clippy, again
* Fix clippy
* Skip render snapshot tests
* Skip testing which needs rendering on CI
* Add tuple sequences
* Address review comments and clippy
`test-log` is used with logging to set up `env_logger` for each
test and was only used in the box constraints code. This code
doesn't actually use logging, so this wasn't doing much.
Daniel McNab