With trait upcasting stabilised in Rust 1.86, we can make use of it in
`DynMessage`.
This also makes `DynMessage` into a struct, because that reduces the
risk of Rust Analyzer messing things up; it liked to confuse the
`Message` trait with the `Message` generic. That is, the prior state was
effectively `trait View<Message = Box<dyn Message>>`, which sometimes
led to things like: `Box<dyn Box<dyn Message>>`.
I've ignored most of the changes and the projects still compile and test
fine. Changes I did commit:
Add `+ use<>` after functions.
Remove `ref mut` from some patterns.
Bump MSRV.
Apply new rustfmt format.
This removes the need to ignore `unused_qualifications`.
The `extern crate std` isn't *strictly* needed, but it will make future
debugging easier (you can do `println` or `dbg!`, for example).
Having `Box<dyn Widget>` implement the `Widget` trait is a crutch that
makes a bunch of things more complicated.
It leads to double-boxing in cases when the `dyn Widget` is itself a
`Box<dyn Widget>` (especially since the arena's current implementation
boxes all widgets by default), makes it harder to reason about
downcasting, and ends up producing a lot of code to handle the edge
cases.
On the xilem side, `Box<dyn Widget>` is slightly redundant with
`DynWidget`.
This PR still leaves a lot of boxing. On the long term, we'd like for
the arena to pack arbitrary widgets efficiently using some kind of
archetype scheme, but in the meantime, boxing will have to do.
Changes in this PR:
- New `FromDynWidget` trait that maybe-downcasts widgets to a
maybe-sized `Widget` type.
- Most places that accept `Widget` now accept `Widget + ?Sized`.
- Remove `impl Widget for Box<dyn Widget>`.
- Replace all instances of `WidgetPod<Box<dyn Widget>>` with
`WidgetPod<dyn Widget>`.
- Replace all instances of `xilem::Pod<Box<dyn Widget>>` with
`xilem::Pod<dyn Widget>`.
- Rename WidgetPod to WidgetBox in xilem_core example to avoid
ambiguity.
Most of the change is remove the `expect` and run `cargo fix`.
For the orphan view, I've added a blanket exception. At the moment, this
only applies to String, but the
I did try using `#![no_implicit_prelude]` in that module, but there are
a lot of useful things in the implicit prelude, it was worse than the
exception.
I needed this in xilem_web, I could've used `Arc` as well, but I think
it's fine to add this for consistency when an `Arc` is not needed.
It's basically copy-pasta of the `Arc`. (I don't think a macro is worth
it here?). Had to fix some resulting issues in the `Templated` view (due
to ambiguity?).
---------
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
This allows exceptions to be burned down on a per-crate basis, rather
than needing to be addressed across the whole codebase at once.
Additionally, this now follows completely the Linebender lint set,
except for the unexpected-cfgs. I don't think I've introduced any
behaviour changes in this PR.
* 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.
Previously the modifier systems had design issues i.e. bugs (non-deleted
styles/classes/attributes), and were unnecessary complex.
This aims to solve this (partly) by not using separate traits, but
concrete types and a different mechanism that is closer to how
`ElementSplice` works.
There's a few fundamental properties that composable type-based
modifiers need to support to avoid surprising/buggy behavior:
* Minimize actual changes to the underlying element, as DOM traffic is
expensive.
* Be compatible to memoization: e.g. a `Rotate` view should still be
applicable to possibly memoized transform values of the underlying
element.
* Recreation when the underlying element has changed (e.g. with a change
of variants of a `OneOf`).
To support all this, the modifier system needs to retain modifiers for
each modifier-view, and track its changes of the corresponding view.
Previously all elements were directly written and separated with markers
into a `Vec` to limit the boundaries of such views, but this had issues,
when e.g. all modifiers were deleted (e.g. clearing a `Vec` of classes),
by not reacting to this (I noticed that issue in the todomvc example
with the footer).
With this PR, the count of modifiers of a modifier-view are directly
stored either (hardcoded) in the view impl or its view state, which
cleans up the concrete modifier elements (such as `AttributeModifier`,
not including a separate `Marker` variant), and makes it less prone for
errors (and is slightly less memory-intensive).
The API to use these modifiers in modifier-views was also redesigned to
hopefully be more straight-forward/idiomatic. But as mentioned above
there's still challenges, which introduce complexity (which I'd like to
hide at least for simpler cases than these modifiers, likely in a future
PR).
All of this should now be documented in the new `modifier` module, where
now the modifiers `Attributes`, `Classes` and `Styles` reside. Other
views (like events) may also end up there...
One interesting aspect compared to the previous system is the use of a
new trait `With` for modifiers.
Instead of (roughly) `Element: WithStyle`, it works with `Element:
With<Styles>`.
This prevents all kinds of reimplementations of something like
`WithStyle` for elements.
This gets especially visible in the `one_of` module, which now can be
covered by a single blanket implementation.
Further the cargo-feature "hydration" was deleted, as it causes more
headaches to maintain than it really brings benefits (minimally less
binary size), depending on the future, it may or may not make sense to
reintroduce this.
Phew, fixing (future) clippy-lints is grunt-work (I enabled
`unnameable_types` for this), this is by far not complete, mostly
xilem-side, but at least a small step towards enabling more of our lint
set.
There's a few "drive-by fixes" like hiding `View::ViewState` types in
Xilem (I don't think we generally want to expose these), or exposing
event types in xilem_web.
I would suggest disabling the `allow_attributes_without_reason` lint for
now, so that we can update the rust version. I feel like adding comments
next to these is just unnecessary extra-work. I think adding more
reasons should probably be a separate pass, after a rust version update,
so that `#[allow(..., reason="")]` is supported.
It's possible to avoid returning the `ViewElement::Mut` in
`View::rebuild`, while having access to the element *after* a child view
was rebuilt.
This PR removes that again making the signature a little bit cleaner,
and also cleans up a lot of other stuff:
* `Mut<'_, Self::Element>` can be shortened to `Mut<Self::Element>`
* `use xilem::core::*` instead of `use xilem_core::*`, this is
especially useful in the examples, to avoid newcomers giving the
impression, that an additional dependency xilem_core is needed.
* Various cosmetic stuff, like one typo fix, empty line between
doc-comment (as (nightly) clippy currently bleats for me)
For more context see
https://xi.zulipchat.com/#narrow/stream/354396-xilem/topic/.E2.9C.94.20.60.26mut.20ViewElement.3A.3AMut.3C'_.3E.60.20in.20.60View.3A.3Arebuild.60.3F
This is another intermediary PR for the "restrict widget creation to
Mutate pass" feature.
The basic idea is that, in the near future, it will be impossible to
create a WidgetPod without a handle to the arena. In my current WIP
code, that handle is passed through ViewCtx. Therefore, this PR changes
all the sites in xilem that create a Pod and has them use a ViewCtx
method instead.
I've tested most xilem examples and they all worked (except for
variable_clock, which currently panics in the last main commit).
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.
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 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>
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>
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.
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>
Daniel McNab