The [adapt](https://docs.rs/xilem_core/latest/xilem_core/fn.adapt.html)
`View` has use cases around message handling, especially around
immutable data structures. See also [Raph's blog
post](https://raphlinus.github.io/rust/gui/2022/05/07/ui-architecture.html#finer-grained-change-propagation-memoizing).
However, the API currently committed is incompatible with #1079.
This PR adds `map_message`, a view which handles the use-case of
handling every possible message (which as far as I can tell, was only an
accidental benefit of adapt, but what most users were using it for).
It's clear that our message model still needs work, but that isn't a
priority at the moment.
Outside of this, the API of `adapt` post #1079 isn't obvious to me. None
of our current examples are using its interesting power (which is
accessing the state you passed to the child after the child runs).
Because of this, I don't think redesigning it is worth the time it will
take to do so for me at the moment, but having it in its panicky state
isn't great.
My intention is to make an issue to redesign and restore this (which I
don't plan to work on), if this is approved.
---------
Co-authored-by: Philipp Mildenberger <philipp@mildenberger.me>
Despite the line diff number, there are almost no content changes in
this PR.
* [One line per
sentence.](https://linebender.org/wiki/formatting-scheme/)
* Updated badges. Of note is that the repo level badges are not
finalized, but I updated to the latest checkpoint. After further
discussion has happened in
[Zulip](https://xi.zulipchat.com/#narrow/channel/419691-linebender/topic/Bikeshedding.20badges/with/452312397)
we can once again update them.
* Reordered some sections to be in consistent order between crates.
* Gave `masonry` an actual `README.md`.
* Updated some references to `Masonry` with `Masonry Winit` to reflect
the new state of things.
* A few miscellaneous tidy-ups.
[Matt
proposed](https://xi.zulipchat.com/#narrow/channel/317477-masonry/topic/Proposed.20change.20to.20the.20split.20between.20core.20and.20winit.20integrat/with/516903214)
renaming the Masonry crates again. The proposal received positive
feedback and so now is the time to do it, before we publish.
The proposal goes deeper than just renaming. However, in the interest of
time and review scope, this PR implements just the renaming part.
Getting the crate names right for publishing is paramount. API changes
can happen later as follow-up work and delays there won't block
publishing.
---
For git blame benefit we wanted to split #965 into two parts. This PR is
the first part that renames the crates. A follow-up PR will rename the
directories.
The main change is to change the names of the crates as registered in
the `Cargo.toml` files. The folders these projects are in aren't
renamed, but since most snapshot test files include their crate name, a
lot of files end up being renamed as well.
This change is done very carefully to minimize the number of changed
files, and use almost only file renames.
This is both for avoiding merge conflicts, keeping file history
unbroken, and keeping the PR easy to review.
A future PR will rename masonry to masonry_core, masonry_winit to
masonry change all the doc tests and snapshots that depend on those
names, etc.
After *that*, future PRs will have actual code changes splitting winit
away from masonry_core.
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>
Daniel McNab