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 brings the `PointerButton` enum from glazier and has all code
outside of the winit event loop integration using it.
For now, it has a `todo!()` for the `MouseButton::Other` as it isn't
clear what that is for.
Note that this adds a link to a section added in
https://github.com/linebender/parley/pull/69
I removed Taffy from the diagram for simplicity, and because Taffy's
current integration is in flux.
Overall I think the Xilem README is in desperate need of a rewrite, and
this PR should be considered a stopgap. Further PRs should better
integrate the ecosystem descriptions into the README, move some sections
around, etc.
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!
This bumps the `accesskit_consumer` version in `Cargo.lock` to the next
minor version (`0.19.1`).
That version includes better error messages when AccessKit panics.
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.
This allows for running `masonry` with an externally managed event loop
for integrating with an application that is already running an event
loop.
* Expose `PointerState` to allow creating `PointerEvent`
* Expose `WindowEvent` to allow managing window size and scale factor.
* Make `DriverCtx` usable from outside the crate. While this struct was
already `pub`, the sole member of it was not.
In the call to updating the hot state from the widget pod, the
`mouse_pos` is already of the right type, so it doesn't need to try to
reconstruct itself as the right type.
This is different from another call site (in `contexts.rs`) where the
`mouse_pos` is an `Option<Point>` and so it does need reconstructing.
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`.
This ports the `Memoize` view from old xilem, slightly enhances it, by
checking whether the given view callback is a non-capturing closure and
not a function pointer (by asserting `std::mem::size_of::<F>() == 0`)
It also ports the `Arc<impl View>` and `Arc<dyn AnyMasonryView>` from
#164 including the example there to show how these two forms of
memoization can be used.
Currently, the only legit typo being found is `seeked` but I'm not sure
what to do about that.
Would be nice to check for new typos in CI anyways, right?
---------
Co-authored-by: Kaur Kuut <strom@nevermore.ee>
These standardized options can make code a little nicer. Right now they
don't change anything, though they include an implicit commitment to
adopt the # `imports_granularity = "Module"` and `group_imports =
"StdExternalCrate"` settings.
While these settings are unstable, we can apply them with rustfmt
nightly without actually committing to using nightly in CI. We should
progressively move parts of the codebase towards that format in future
PRs.
---------
Co-authored-by: Kaur Kuut <strom@nevermore.ee>
For some reason the recent version of Trunk refused to serve some of the
examples due to them missing the <html> tags. Adding the tags calms it
down and allows it to work again. Trivial change, but would save someone
the pain of having to fix examples before running them with trunk serve.
Co-authored-by: Alex Pyattaev <me@example.com>
`cursor_icon` is a crate that is used by `winit` to provide its
`CursorIcon` type separately from the `winit` crate.
This re-exports the `CursorIcon` from `masonry` and then uses that
rather than via `winit:🪟:CursorIcon`, allowing the use of the
`CursorIcon` without having to independently discover its provenance.
This is also one step towards not requiring `winit` within the `masonry`
internals apart from the actual window / event loop management.
Doing some investigation, the issues I'm seeing is that ibus is a bit/a
lot broken around compose keys
But this has correct behaviour for me. This matches the documentation of
the `winit`
[`Ime`](https://docs.rs/winit/latest/winit/event/enum.Ime.html) event.
Wired up some more existing masonry flex properties so they can be set
on the flex view.
I was messing around with a dummy example to try out the v0.1 and
noticed I couldn't easily center something because flex was only
exposing direction not alignment/cross-alignment. It looked like all the
logic already exists in masonry so it was just a matter of wiring it up.
This is my first contribution so sorry if I missed some steps.
Sidenote: I didn't see any examples of testing that a view updates the
underlying element so I am guessing that is still tbd. If someone has a
suggestion for a good way to do that I am happy to try it out.
I'm also not sure what the etiquette is on adding/editing examples so I
just included the example I was using to verify it worked but no stress
if you want to remove it.
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.
Previously, filling up the line would overflow the right border of the
box, because the `max_advance` was too big.
This improves the margin hack, and also fixes the resultant issue.
---------
Co-authored-by: Bruce Mitchener <bruce.mitchener@gmail.com>
Fixes the issue described in #265.
I *think* this is the proper fix, it seems to be similar as in previous
xilem (where I think that pass is called `ViewContextChanged`).
Daniel McNab