With trait upcasting stabilised in Rust 1.86, we can make use of it in
`DynMessage`.
This also makes `DynMessage` into a struct, because that reduces the
risk of Rust Analyzer messing things up; it liked to confuse the
`Message` trait with the `Message` generic. That is, the prior state was
effectively `trait View<Message = Box<dyn Message>>`, which sometimes
led to things like: `Box<dyn Box<dyn Message>>`.
It's no longer correct to add the window-relative origin of the widget
to the bounding rectangles of the text runs, since we now apply a
transform on each widget's AccessKit node.
The textarea widget currently doesn't support multiline input because
the Enter key is used to trigger the TextEntered action. This commit
makes this behavior configurable by adding
masonry_core::widgets::InsertNewline.
This is the first follow-up from the MVP of virtual scrolling. The valid
range is used to limit where in the id space can be scrolled to. This
will be widely useful for many (most?) virtual scrolling use cases.
Consider for example http_cats; the valid range would be 0..the number
of status codes.
Depends on #904.
Add BackgroundColor, BorderColor, BorderWidth, CornerRadius and Padding
properties.
Modularize button painting code.
Paint border after background to get slightly better border appearance.
Update screenshots.
Add screenshot test using properties.
This is a minimum viable virtual scrolling widget, making the following
assumptions:
- It does not *care* about scrollbars. This has several big advantages:
- It allows for "infinite" virtual up and down-scrolling
- It allows for much more control by users of how the scrolling happens
(e.g. a date based scrollbar)
It does *not* assume that each item has a fixed height, and instead uses
some best-effort heuristics to work out which items should be loaded.
We've done some thinking about how to handle arbitrary transforms of
child widgets. Essentially, the only way we can reasonably handle this
is for each child widget to be automatically clipped to their layout
rectangle (...maybe e.g. 20% larger than it; that's hard because if we
don't use fixed margins then the variable scroll controller needs to
know about it).
This also does not handle focus and other details around (e.g.)
textboxes properly; it's not actually possible for the VirtualScroll
widget to know which child has the focus, so it can't keep that widget
around. Saving the textbox state would be nice, but requires a redesign
of a lot of things, essentially.
Fixes#51
---------
Co-authored-by: Bruce Mitchener <bruce.mitchener@gmail.com>
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`.
This is unused. It was added to Druid in
<https://github.com/linebender/druid/pull/842>.
In the `winit` world, this would be done instead by customizing the
window creation with `WindowAttributesExtMacOS` and the
`with_accepts_first_mouse` function. (So it would no longer be something
that you have to check on every mouse click event as it is part of the
`WinitView` within `winit`.
Any new widget code needs to have full docs.
Not having `missing_docs` trigger by default for new widgets is quite
bad.
See #875 and #882 for cases where this over-broad allow has bitten us.
The comment about not using `expect(missing_docs)` because of
rust-analyzer is confusing to me; I don't run into an issue. It might
have been https://github.com/rust-lang/rust/issues/130021, which is now
fixed. That comment should have had a link to an upstream issue for more
context.
While on slow internet connection I noticed that copyright notice is
conflicting with the spinner:
So I paired the image with the copyright notice to display it only when
image is loaded. I hope this is not complicating the example code.
---------
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
### Highlights
- Make the Masonry Split widget generic over its children (fixes a todo)
- Adds a new Xilem view for the widget
- Updated the `http_cats` example to use it for the main divider.
---
I'm unsure how exactly the `message` function works on a Xilem view as
it was hard to find documentation on that, so I've tried my best to
implement it, by looking at other views. Please double check that I did
it right.
I also changed some defaults on the split widget. First, I changed
`draggable` to default to true, since I believe this is the intended
behaviour for the view, similar to how a button is not disabled by
default.
I changed the constructors of the widget to not include the `split_axis`
but rather let it be optional with vertical (row) being the default
axis. I feel this made it more ergonomic to integrate with Xilem.
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.
I've ignored most of the changes and the projects still compile and test
fine. Changes I did commit:
Add `+ use<>` after functions.
Remove `ref mut` from some patterns.
Bump MSRV.
Apply new rustfmt format.
This removes the need to ignore `unused_qualifications`.
The `extern crate std` isn't *strictly* needed, but it will make future
debugging easier (you can do `println` or `dbg!`, for example).
so that it's available to widgets that can fix blurry lines due to bad
overlapping positioning of its internal elements
partially addresses https://github.com/linebender/xilem/issues/869
---------
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
I don't think there is a reason not to, and you need winit for some
types so currently you must define the crate yourself, which risks
version errors etc.
I wanted to create a custom button view, but when needing to pass to the
masonry type could not convert the pod to a widgetpod.
So I'd like to make this method pub to allow that
---------
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
Daniel McNab