This only supports copy-pasting strings, not rich text. And the way
Ctrl+V is detected is somewhat dubious.
But it does effectively add clipboard support to Masonry apps.
Ideally, on the long term, we may want to be able to programmatically
request clipboard contents; I'm not sure how to implement that cleanly
given RenderRoot's architecture, without making masonry_core depend
directly on a clipboard-handling library.
---------
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
Instead of re-exporting `cursor_icon` from `masonry_core` and `masonry`,
we can re-export the single type that matters (`CursorIcon`) from
`masonry_core::core` / `masonry::core`.
Use type alias in various places.
Avoid referencing smallvec from widget code.
Fixes#1141.
---------
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
[Anymore](https://github.com/linebender/anymore) is a new crate which
we're developing for use in Xilem and Masonry. This crate contains the
`AnyDebug` trait, which is a supertrait of both Any and Debug. We are
developing this because Xilem Core and Masonry both want support for
dynamically typed messages with introspection for debugging, but those
have to use the same trait to allow proper interoperability.
See also [#rust ui >
Anymore](https://xi.zulipchat.com/#narrow/channel/422907-rust-ui/topic/Anymore/with/528892562)
This crate has not yet published to crates.io; I intend for us to do so
once we have migrated Masonry's `Action` to being only a wrapper around
`Box<dyn AnyDebug + Send>`. See also discussion in #1105
This is not very far fleshed out, but should give an idea of the
strategy.
```rust
#[derive(Debug)]
struct MyResource(&'static str);
impl Resource for MyResource {}
fn app_logic(...)-> impl View<...> {
provides(
|app_state: &mut AppState| MyResource("abc"),
with_context(|res: &mut MyResource, app_state: &mut AppState| { /* res.0 is "abc"*/ })
)
}
```
You can run `mason` to see this working
---------
Co-authored-by: Philipp Mildenberger <philipp@mildenberger.me>
Currently, the examples live in `masonry_winit` and use `masonry` with
the `testing` feature enabled. Once these examples move back into
`masonry`, then this becomes more annoying and it is easiest if they
just depend separately on `masonry` and `masonry_testing`.
Now that we don't use `masonry::theme::default_property_set()` and we
have the re-exports in place from `masonry_core`, we can remove our
dependency on `masonry` itself.
We have things that are deps of `masonry_core`, `masonry`, and
`masonry_testing` and if you use `masonry_core`, you need to know that
and use the right versions.
Instead, we should be exporting these things from `masonry_core` and
using them from there.
This updates `masonry_testing` to use things from `masonry_core` instead
and subsequent commits can further improve upon this with the `masonry`
crate and so on.
This is an exploration into using the Mastodon API, continuing work on
the hero app.
The actual changes here won't be all that useful, in the long term, but
it's helpful for getting an understanding of how to use the API.
One big, unfortunate surprise is that we really need some HTML parsing
(although only as described [in the
docs](https://docs.joinmastodon.org/spec/activitypub/#sanitization)).
That is something I'm not looking forward to!
One discovery in this PR is that our logging isn't set-up for the first
`build` in Xilem. That makes sense with how logging is owned, but it's
also very unfortunate).
I do intend to land this, to keep progress moving in a piecemeal way,
and potentially to allow collaboration. It might be that hero app PRs
should be largely rubber-stamped. Note that there are "real" changes to
Xilem in this PR (limited to new re-exports)
If you don't have the accessibility feature enabled in your OS then you
don't run the accesskit_consumer code which can lead to accessibility
being broken without you noticing.
Of course you should still do manual accessibility testing but this
change ensures that the accesskit_consumer code at least doesn't crash
if your app is tested with the TestHarness.
`masonry_winit` and its examples shouldn't have a direct dependency on
`vello`. This is especially true for example code as it should be able
to be copied and pasted without having to add its own dependency upon
`vello`.
People should use `masonry` for all of the general purpose stuff and
only use `masonry_winit` for the Winit integration.
Further cleanups to the `masonry_winit` crate can come after this.
This is a result of:
```
cargo update --ignore-rust-version
cargo upgrade --ignore-rust-version
```
Most notably this gets us `color` 0.3.1 which fixes nightly compilation.
[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.
- Remove file hover/drop events from `PointerEvent` because they were
never mapped and could never be mapped (since they relied on pointer
positions which are not available in file hover on winit.
- Remove modifier change events from `TextEvent`, since nobody uses them
anywhere, and new `PointerEvent` and `KeyboardEvent` include them.
- Remove pointer state from events that are unlikely to have new state
when they occur (enter/leave/cancel).
- Remove redundant default widget event handlers and imports.
This is basically the upcoming Parley 0.4.0, but right now pointing
towards the latest git rev.
The snapshots have changed because line height layout code improved in
Parley.
Fixes#933Closes#936
With W3C specs, I think we should be mapping meta / super differently
than we were before. This will change again with winit 0.31 where the
names of those keys on the winit side will have changed. (And also, much
of this particular mapping won't be necessary.)
The bulk of this change is that in `keyboard-types` 0.8, the `Key`
enumeration has changed to have a separate enumeration for `NamedKey`
values.
---------
Co-authored-by: Mads Marquart <mads@marquart.dk>
With #936 stalling but Matt wanting AccessKit changes I decided to split
out parts of #936 into this PR. This brings in Parley from March 25th,
2025 and that gets us the AccessKit update.
Have all screenshot tests store their reference file in
`<CRATE_ROOT>/screenshots/<TEST-NAME>.png`.
Move all existing screenshot tests accordingly.
Add namespace to most test names to avoid filename collisions.
Document the changes.
Remove serde dependency from `masonry_core`, as previously it was only
used to look up the path to store the test in.
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.
Remove nv-flip dependency and use pixel-by-pixel comparison instead.
Reduce error tolerance in tests.
Update a few outdated screenshots.
Create `assert_failing_render_snapshot` macro to make sure our diffing
infrastructure catches regressions.
Fixes#893.
This is the first step towards #907.
This doesn't split the crate yet, but adds a translation layer between
winit and Masonry to facilitate that split.
`tempfile` on Unix pulls `rustix`, which has a 9.19s single-core build
time on my machine, and was unused in our code.
`tempfile` is still a indirect dependency through `uds_windows`, which
is fine because in that dependency path (windows-only) doesn't pull
`rustix`.
Add `Properties[Mut]` argument to widget methods.
Add a third TreeArena to sort per-widget arbitrary property values.
For the type-to-value map, I considered the following crates:
- https://docs.rs/typemap/latest/typemap/
- https://crates.io/crates/typemap_rev
- https://crates.io/crates/typemap-ors
- https://github.com/chris-morgan/anymap
- https://github.com/reivilibre/anymap3
Of these, anymap3 is the only one actively maintained (last commit less
than 12 months ago). The code source itself is extremely light and
simple; we may or may not decide to roll out our own implementation down
the line.
Add a BackgroundBrush property used by SizedBox as a proof of concept.
Note that SizedBox still has its `background` field, but we should
expect future widgets to use almost *exclusively* properties; properties
usually shouldn't be redundant with local fields.
To get there, we'll first need to better integrate properties in Xilem.
Some notes:
1) The accessibility of this example probably isn't great. Not sure what
to do about this.
2) Our layout primitives aren't great; we use a grid, but ideally the
number of rows would be reactive to the available space.
3) The pagination is slightly hacked together - it should really try and
give you page numbers. I'm not planning to address this, unless someone
provides the algorithm
This was originally created to act as a screenshot for
https://github.com/linebender/linebender.github.io/pull/56
Olivier FAURE