There is one "semi-false-positive" lint triggered, which I have fixed.
Otherwise, the required
```
cargo upgrade --ignore-rust-version
cargo update
```
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.
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)
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>
In most cases, you want a button which only actuates when the primary
mouse button is pressed, so the easy case is still that. This is a short
term hack, because e.g. the active state is still based on any button
being pressed, not just those we are interested in.
That is, we probably need to represent a set of buttons we are
interested in. However, this change minimally unblocks additional work
with Xilem. In particular, see [#xilem > Minesweeper converted from Iced
to
Xilem](https://xi.zulipchat.com/#narrow/stream/354396-xilem/topic/Minesweeper.20converted.20from.20Iced.20to.20Xilem).
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>
This was initially a supposed to be a small documentation pass, which
grew into a few changes:
- Adding back a to-do-list example.
- Fixing the bugs revealed by that example (infinite bounding boxes,
wrong accessibility handling in Portal, etc).
- Making sure all widgets return the correct spans instead of the
less-useful default one.
- Adding a trace to the layout pass for easier debugging.
Overall I'm pretty happy with this!
Recently, `instant` has been marked as unmaintained by the maintainer. A
suggested replacement is `web-time`, which is used by `winit` and is
already in our dependency tree.
The current nightly issues warnings for unknown cfgs, so we need to
suppress some of these for now.
Even though these are only needed for `masonry`, we put them in the
workspace configuration due to limitations in how the lints table is
configured and overridden in current versions of Cargo.
This removes a class of dependencies from within both `masonry` and
`xilem` on the `winit` crate where we can just use `dpi` directly
instead.
The `dpi` crate is meant (like `cursor_icon`) to be a shared ecosystem
crate rather than only for usage with `winit`.
These are the results of running
```sh
cargo upgrade --ignore-rust-version
cargo update
```
in preparation for the upcoming release.
These are semver compatible updates.
The `image` crate has a number of dependencies which aren't needed in
the core masonry crate, so we can turn off the default image format
support and only enable "png" when used as a dev dependency.
Also, make it a workspace dependency at the same time so that the
version is only stated in a single location.
Add AccessKit dependency.
Add accesskit_winit dependency.
Add methods to the Widget trait which create the accessibility tree and
react to accessibility events.
* Rename classic `xilem` to `xilem_classic` and the new `xilem_masonry`
to `xilem`.
No directory structure changes yet to avoid merge conflicts before
RustNL.
* Base common dependencies on workspace dependencies.
* Bump `masonry` version to `0.2.0`.
* Remove some legacy docs.rs configuration inherited from Druid/Glazier
that is no longer needed.
* Unify ordering of properties.
* Create a minimal xilem_masonry
* Add a first draft of view sequences
* Implement a flex view
* Fix clippy
Some of these suggestions are kind of bad
but that's by-the-by
* Update CI to 1.77
* Skip masonry docs in CI
* Clippy, again
* Fix clippy
* Skip render snapshot tests
* Skip testing which needs rendering on CI
* Add tuple sequences
* Address review comments and clippy
`test-log` is used with logging to set up `env_logger` for each
test and was only used in the box constraints code. This code
doesn't actually use logging, so this wasn't doing much.
* Update vello and parley deps...
... and everything else, apparently. This pushes the new font code changes through the ecosystem.
Brings everything into sync and should put us in a good place to start releasing.
This works as is but depends on a vello commit that is still under review: linebender/vello#425 should land first and this should be updated with the new git rev before merging.
* fmt :(
* update git revs
* Merged xilem_svg into xilem_html
* Renamed xilem_html to xilem_web and removed xilem_svg
* xilem_web: factor pointer to root, as it can be used for all Elements and refactor slightly
* Rename example
* xilem_web: Make BoxedView public
* Rename cx.add_new_attribute_to_current_element -> add_attr_to_element and IntoAttributeValue::into_attribute_value -> IntoAttributeValue::into_attr_value
* Add the `fill` and `stroke` attribute to the `g` element
* Fix text widget layout invalidation
* Gitignore .DS_Store files
* Add downcast_ref method to Pod
* Add compute_max_intrinsic method to Pod
Implement compute_max_intrinsic for Box<dyn AnyWidget>
* Add TaffyLayout view and widget
* Add background_color support to TaffyLayout
* Add taffy example
* Added all MathML elements
* xilem_html: Add all SVG elements and DOM interfaces, and an example using MathML and raw SVG
* Cargo fmt
* xilem_html: Reduce boilerplate in elements, by adding a new macro match arm
* xilem_html mathml_svg example: Remove unnecessary stuff in index.html
* xilem_html: Use `mod`s for each element namespace (html, mathml, svg)
* xilem_html: Introduce DOM interface traits to make per DOM element typing possible and flexible
* Cleanup a little bit (remove artifacts from refactor)
* Use separate sealed interfaces to avoid blanket trait impl collisions
* Add generic params T and A to event views and Attr via PhantomData, to avoid inference issues with composed types
* xilem_html: Refactor DOM interface macros
* Add ancestor *and* descendent composable macros
* Added a macro to correctly and conveniently implement dom interfaces for interface restricted Views, this is used currently for the Attr view and the event views
* xilem_html: Add namespace to element generation and refactor element/attribute logic into separate functions
* xilem_html: Remove unnecessary features
* xilem_html: Implement DOM interface traits for Adapt and AdaptState
* xilem_html: Refactor OneOf views
* Eliminate associated trait bound for the View, for easier use
* Add additional OneSeqOf view sequences, to avoid removing the ViewMarker super trait bound on Element
* implement all dom interfaces for the OneOf views
* xilem_html: Reorder generic type parameters in composing views such as `Attr`
* Make xilem_svg into a library
Instead of having the demo app hardcoded, make it a library with a web_examples folder, just like its xilem_html sibling. This patch doesn't change the example or any functionality.
* Migrate KurboShape to ViewExt
Exports a `ViewExt` trait, and wires up types so that type inference can flow through the methods on this trait. That removes the hacky `KurboShape` workaround.
* clippy
* Add fill and stroke
Supports very basic fill and stroke (solid colors, stroke width but no other style parameters).
* rustfmt
* Address review feedback
Fix some cut'n'paste errors, and update README slightly.
Daniel McNab