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.
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.
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 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:
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>
Olivier FAURE