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.
This was remarkably painless.
I especially appreciate @taiki-e providing an install-action which does
90% of the CI work for us.
---------
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
Takes ideas from #235 (in particular the masonry side).
This implements support for explicit spacers in the `Flex` view and flex
parameters for views (see examples `flex` and `mason` for more details).
It also adds a way (`AnyFlexChild`) to dynamically switch between
spacers and widgets (with optional flex parameters).
`masonry::widget::Flex::layout` is also updated to be in sync with
current druid.
---------
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
See discussion in [#linebender > Standard Lint
set](https://xi.zulipchat.com/#narrow/stream/419691-linebender/topic/Standard.20Lint.20set)
Of note: I have taken steps to ensure that this can be practically
reviewed by *not* applying most of the lints.
The commented out lints make good follow-ups
---------
Co-authored-by: Olivier FAURE <couteaubleu@gmail.com>
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.
These changes allow you to create a masonry or xilem app that is driven
by an external event loop.
## Masonry
Existing method for creating masonry app:
```
masonry::event_loop_runner::run(
masonry::event_loop_runner::EventLoop::with_user_event(),
window_attributes,
root_widget,
app_driver,
)
.unwrap();
```
Instead you can now do this:
```
let masonry_state = MasonryState::new(window_attributes, &event_loop, root_widget);
let mut app = AppInterface {
masonry_state,
app_driver: Box::new(driver),
};
event_loop.run_app(&mut app)
```
Where AppInterface implements the winit
ApplicationHandler<accesskit_winit::Event> trait.
## Xilem
Existing method:
```
let app = Xilem::new(state, app_logic);
app.run_windowed(EventLoop::with_user_event(), title)?;
```
Now:
```
let xilem = Xilem::new(0, app_logic);
let (root_widget, app_driver) = xilem.split();
let parts = xilem.split();
let (root_widget, app_driver) = (parts.root_widget, parts.driver)
// and then create masonry app just like above using root_widget and app_driver
```
Also adds example/external_event_loop.rs which duplicates
example/flex.rs but with an external event loop.
---------
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
Related to #44
We don't have any necessary unsafe code, and I don't think any of us
want to lose that.
(Vello is also no longer laundering the unsafety wrt surface creation
thanks to a recent wgpu release)
I had trouble getting masonry to compile for iOS due to a winit platform
method call that's not supported. There's already a cfg for android so I
just added iOS to it.
Reproduction:
```
cargo check --target aarch64-apple-ios
```
---------
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
This was most recently updated in
https://github.com/linebender/vello/pull/505
The main differences are:
1) Greater concurrency between clippy and testing
2) More explanations
3) MSRV checking
4) Use of `cargo hack`
5) WASM checked in CI
I've also added the current values of our MSRVs to the main three
crates.
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>
Format:
```rust
label("everything").text_size(42.)
```
and the same with `prose`.
I've also added `font_size` aliases for these, because people will
expect it to have these names.
Philipp Mildenberger