I opened https://github.com/linebender/xilem/issues/473 earlier today,
but I realized after looking at the code that it would be super simple
to implement!
Copying over some context from that issue:
- I'm working on a graph renderer using Vello.
- I'm porting it over to a Masonry widget, so that I can build a UI
around it.
- In doing so I noticed there wasn't support for winit's `PinchGesture`,
which I had been using before when messing around with this on my macOS
device.
Please let me know if y'all feel like this is appropriate to include
inside of `PointerEvent`!
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`.
I think I've covered every pub item at the top level.
It also renames (taking `Attributes` as example)
`start_attribute_modifier` -> `rebuild_attribute_modifier`,
and `end_attribute_modifier` -> `mark_end_of_attribute_modifier`, as I
think that makes it more clear what these methods do.
`start_attribute_modifier` was a noop in `View::build` and may lead to
buggy behavior when `DomNode::apply_props` is called before every parent
`View::build` has done modifying the props. This should make
`DomNode::apply_props` robust. And `AfterBuild` is fixed now with that.
This is mostly a first step towards SSR.
But we can use hydration to speed up creation of long (non-virtualized)
lists with the `Templated` view.
`Templated` stores a deep copy of the DOM node of the first occurence of
its `impl DomView` based on the `TypeId` in the `ViewCtx`,
and reuses it on every further invocation, where it will be hydrated and
updated based on the new attributes.
As it uses an `Rc` to achieve this, it also supports memoization,
similar to an `Arc<impl View>`.
Hydration is currently feature-gated, as it produces a little bit more
binary bloat. Though it's little enough to this being justified as
default.
---------
Co-authored-by: Markus Kohlhase <markus.kohlhase@slowtec.de>
This is part of the "Pass Specification" RFC:
https://github.com/linebender/rfcs/pull/7
Rename WidgetCtx to MutateCtx.
Add a mutate pass.
Add a `mutate_later` context method to trigger that pass.
Refactor `edit_root_widget` to use a version of that pass.
Add a separate constructor for the synthetic WidgetState created in
RenderRoot.
---------
Co-authored-by: Philipp Mildenberger <philipp@mildenberger.me>
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
On mobile platforms, setting the logical width of the window to 400 can
cause the view to overflow on phones with smaller screen widths (such as
the iPhone SE 2nd generation).
<details>
<summary>screenshot of the view overflow</summary>
<img
src="https://github.com/user-attachments/assets/d47c1c88-ace6-4059-a0ed-b5384dcfa207"
alt="screenshot of the view overflow" width="400" />
</details>
It is more intuitive not to manually set the window size. Additionally,
winit does not support set_title and set_resizable on iOS and Android
(calling them does not have any effect).
This is a first step in implementing the "Pass Specification" RFC:
https://github.com/linebender/rfcs/pull/7
Create a `passes` module.
Create event passes.
Create the update_pointer pass.
Remove `WidgetPod::update_hot_state` method.
Move mouse-cursor-handling code to update_pointer pass.
Implement pointer capture.
Refactor the TreeArena code.
---------
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
These either aren't used, aren't implemented, or are just stubs. A new
implementation may or may not take the same approach given changes
within the ecosystem, and if we want these back, they're in the history.
This should fix the issue described in #440 by adding the type of the
`Children` `ViewSequence` to the type of element, which results in
unique types, so `AnyView` should not cause issues anymore. Fortunately
there's no regression with the compilation times here, so an
`AnyViewSequence` doesn't seem to be necessary in that case.
It's jarring for the example to automatically add to the button count,
so this makes it so it only increments while active is true.
---------
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
This is the smallest change possible to make animations work in Masonry.
Essentially, we treat every redraw as a potential animation frame, so
that animations do work.
I've also added the `spinner` view in Xilem to test this out. The
`state_machine` examples uses this.
This is work done for the variable fonts demo.
Should fix#461. This allows a `ViewSequence` (called `DomFragment`) of
`DomView`s as root component.
The `counter` example is updated to show this new behavior.
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 allows returning `impl ViewSequence` as this was previously not
possibly as the `Marker` generic parameter couldn't be named (easily) in
`ViewSequence<..., Marker>`.
This also provides specialized `ViewSequence`s for xilem
(`WidgetViewSequence` and `FlexSequence`) as well as for xilem_web
(`DomFragment`). Additional doc-tests/documentation and a small example
(in `counter`) for xilem_web is provided as well.
This has the drawback to not being able to reeimplement `ViewSequence`
for types that already implement `View`, which was previously possible
(as seen by the now removed `NoElementView` `ViewSequence`
implementation).
And additionally by introducing more boilerplate by having to implement
`ViewMarker` for every type that implements `View`.
---------
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
I'm surprised that this was not noticed yet,
`DomChildrenSplice::with_scratch` previously only appended new elements
to the end of the children of an element in the DOM tree, whereas it
should've inserted it at the current index of the `ElementSplice`. This
should fix this, using a `DocumentFragment` which is shared on the
`ViewCtx` to avoid unnecessary allocations.
`masonry::text::edit::TextEditor` should emit an
`Action::TextChanged(...)` also on `Backspace` and `Delete` if anything
was deleted, so that e.g. `xilem::view::textbox::Textbox` receives this
action. This is already implemented for `Ctrl+Backspace` and
`Ctrl+Delete`.
The code changes are not elegant, but intended to be minimally invasive.
Local `cargo test` failed for the modified and an unmodified code, but
sometimes with different errors—which I do not quite understand.
I apologize in advance for any mistakes on my part, I've never before
worked on open source repos and did not find any guideline for your
project.
From manually testing in Chrome, values between `2**31` and `2**31 - 1`
work, so this takes an `i32`.
It's pretty trivial code, but I think it would be really nice to add
some kind of test, or even just an example which uses it.
What do you think about adding a "misc" example for `xilem_web`, which
exercises a bunch of small features? I was thinking a layout with a
column on the left with a list of items with a larger area on the right.
When an item on the left is clicked, the right side is populated with
whatever that item is.
In this case, the item name would be `ol-li-value`, which when clicked
would show something like this on the right:
```rust
ol((
li("foo"),
li("bar"),
li("baz").value(10),
li("qux"),
));
```
Ideally, this would be compiled as part of CI, to make sure that no
compilation errors are introduced. Any time a small feature is added, a
new item in the "misc" example could be added which uses it.
It would also be nice for development, to have a place where new, small
features like this can be exercised during development. An actual test
would be great, but from quick googling, I couldn't find an obvious way
to test WASM code which runs in the browser. There's
`wasm_bindgen_test`, but that only runs tests in WASM outside of a
browser environment.
This adds a `force` which is basically a specialized `Memoize` without
any bound data.
This also cleans up `Memoize` a little bit (mostly code-aesthetic stuff,
but also adds `State` and `Action` params to the view, so that it
doesn't offer weird surprises when composing it with views like
`Adapt`).
The `Arc` view is also fixed, as it didn't support force rebuilding yet,
which is relevant for e.g. async, e.g. the `MemoizedAwait` view would
not work inside an `Arc<impl View>` currently.
---------
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
This pull request adds a simple calculator that can display binomial
math (ex: 2 + 2 = 4). Math operations with more than two operands are
done by moving the prior binomial results into the left operands.
This pull request also follows the existing convention by masonry's
calculator example to calc_masonry to differentiate them.
Let me know if there are any changes that I should make to improve code
quality.
<img width="404" alt="image"
src="https://github.com/user-attachments/assets/3498913b-dd4d-451c-8fa2-fcd2f7fd26af">
---------
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
I guess I missed this when adding #408, the doc-test should ensure that
`Box<AnyDomView>` is now really a `DomView`.
---------
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
I think we could also create some additional sugar around that, but
since the event is given to the user, they can handle that behavior
anyway.
Fixes#457
Crockeo