There is one "semi-false-positive" lint triggered, which I have fixed.
Otherwise, the required
```
cargo upgrade --ignore-rust-version
cargo update
```
This uses the interface in Xilem Core from #394 and #436
Some thoughts:
1) You only need to specify the number of items in a single match arm.
I.e.
```rust
fn my_view(){
match x {
0 => OneOf3(...),
1=> OneOf9(...),
_=> OneOf9(...),
}
}
```
works. We probably should rename `OneOf9` back again in that case.
2) The example currently isn't that interesting. Any suggestions for a
more suitable state machine would be welcome.
This was remarkably painless.
I especially appreciate @taiki-e providing an install-action which does
90% of the CI work for us.
---------
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
Takes ideas from #235 (in particular the masonry side).
This implements support for explicit spacers in the `Flex` view and flex
parameters for views (see examples `flex` and `mason` for more details).
It also adds a way (`AnyFlexChild`) to dynamically switch between
spacers and widgets (with optional flex parameters).
`masonry::widget::Flex::layout` is also updated to be in sync with
current druid.
---------
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
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.
These changes allow you to create a masonry or xilem app that is driven
by an external event loop.
## Masonry
Existing method for creating masonry app:
```
masonry::event_loop_runner::run(
masonry::event_loop_runner::EventLoop::with_user_event(),
window_attributes,
root_widget,
app_driver,
)
.unwrap();
```
Instead you can now do this:
```
let masonry_state = MasonryState::new(window_attributes, &event_loop, root_widget);
let mut app = AppInterface {
masonry_state,
app_driver: Box::new(driver),
};
event_loop.run_app(&mut app)
```
Where AppInterface implements the winit
ApplicationHandler<accesskit_winit::Event> trait.
## Xilem
Existing method:
```
let app = Xilem::new(state, app_logic);
app.run_windowed(EventLoop::with_user_event(), title)?;
```
Now:
```
let xilem = Xilem::new(0, app_logic);
let (root_widget, app_driver) = xilem.split();
let parts = xilem.split();
let (root_widget, app_driver) = (parts.root_widget, parts.driver)
// and then create masonry app just like above using root_widget and app_driver
```
Also adds example/external_event_loop.rs which duplicates
example/flex.rs but with an external event loop.
---------
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
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)
I had trouble getting masonry to compile for iOS due to a winit platform
method call that's not supported. There's already a cfg for android so I
just added iOS to it.
Reproduction:
```
cargo check --target aarch64-apple-ios
```
---------
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
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>
Format:
```rust
label("everything").text_size(42.)
```
and the same with `prose`.
I've also added `font_size` aliases for these, because people will
expect it to have these names.
Since we're suffering from the orphan rule with the new xilem_core
implementation, we cannot use `View` in downstream crates for external
types such as a `WidgetView` implementation for `&'static str` in Xilem.
This PR adds an `OrphanView` trait which the `Context` of the `View` has
to implement for the type which has an implementation in xilem_core for
this. The `View` impl for these types is basically a proxy for
`OrphanView` (which in turn has the same method signature as `View`), so
downstream crates can achieve the same as with the `View`.
---------
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
Since #314, we request the IME to be positioned every paint cycle. This
triggers a new event from the IME, which is a preedit clear. This IME
event also breaks text selection, which is why we handle it here.
This is still not the fully correct behaviour, but it does at least make
text selection in textboxes work again. We really need to improve our
testing story here.
Also give more detail in the short form of IME events; these events all
have quite different properties.
This adds yet another generic parameter `Message` to the `View`,
`ViewSequence` and `AnyView` trait, such that implementors have more
freedom about what the message is. This is necessary for xilem_web, as a
`Send` bound is not possible to use with wasm_bindgen IIRC. (At least I
had to remove it in the `DynMessage` to get it to compile...).
It was fortunately straight-forward to just add the `Message` param with
the default `DynMessage`. Basically search replace... (I hope I haven't
missed anything, but I went through it twice...)
This ports the `OneOfN` views from `xilem_web` to `xilem_core`.
~~The new marking mechanism for the `ViewSequence` makes it possible to
use the same type as well for an implementation of `ViewSequence`, which
is provided here as well.~~
Because of ambiguity, and needing to specify the explicit type when
`OneOf(impl View)` would be used, where an `impl ViewSequence` is
expected, we have decided to not provide a `ViewSequence` impl, so that
it's not ambiguous, and not necessary to specify the concrete type. We
could instead add separate types for a `ViewSequence` instead like
`OneSeqOf2`.
Since macros make this unfortunately not super readable, for reviewers
of the code [this pre-macro
version](4f786c4282/xilem_core/src/views/one_of.rs)
may be better to look at, the only difference to this, is that this has
slightly enhanced doc comments, and obviously more than just `OneOf2`.
Ports `Adapt` to new xilem_core.
It also adds `MapState` which was previously called `AdaptState` and a
new view `MapAction` which is basically about how elm works.
`MapAction` and `Adapt` is shown in action in the added `elm` example,
while `MapState` can be seen in action in the added `components`
example.
Based on a suggestion from @dfrg.
This appears to have improved performance with the 30_000 hello's
example from ~$\frac{1}{20}$ms to $\frac{1}{160}$ms
So an approx 8x increase in throughput for that scene.
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).
Daniel McNab