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
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
```
This uses the interface in Xilem Core from #394 and #436
Some thoughts:
1) You only need to specify the number of items in a single match arm.
I.e.
```rust
fn my_view(){
match x {
0 => OneOf3(...),
1=> OneOf9(...),
_=> OneOf9(...),
}
}
```
works. We probably should rename `OneOf9` back again in that case.
2) The example currently isn't that interesting. Any suggestions for a
more suitable state machine would be welcome.
Richard Dodd