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
This adds the required context methods for (re)setting the IME area.
These are added to the mutable context types, which I believe is the
right place.
`TextArea` now uses `PlainEditor::ime_cursor_area` to report its IME
area.
Note Masonry currently reports new IME cursor areas only when the widget
itself moves or the focus changes to a new widget, but Parley's
`PlainEditor` determines the IME cursor area based on the selection and
preedit state of the editor, meaning the area can change based on events
as well. Other widgets may choose to have different behavior still.
(It appears Masonry currently doesn't account for the IME area
potentially changing based on relayout, which may be a bug.)
This replaces the old IME area reporting with a check at the end of the
rewrite pass to see if IME is active, and if it is, whether the IME area
has moved. If it has, the new area is reported to the platform.
---------
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
As noted in
https://github.com/linebender/xilem/pull/772#pullrequestreview-2485087588,
this seems to be a really cheap but quite effective optimization, as we
have `hashbrown` already in our dependency tree.
I've noticed speedups of the rewrite passes of up to >100%.
On average about 20-50% and is also definitely noticeable (smoother and
less latency).
Another quite interesting observation with my (admittedly not really
reproducible) performance tests,
is that the safe tree arena is actually faster than the unsafe version
(roughly 10-30%), and tells yet another time that benches are really
important while optimizing...
Rough overview of my performance tests/benches:
I've mostly hovered over 10000 buttons in the mason example while
testing, but every second or so a new button is spawned and also this is
quite a bit faster.
I did a quick'n dirty `Instant::elapsed` in the event loop (so rendering
is not included, but I think there's also a speedup as we're iterating
the tree).
I've had a try at implementing the unsafe `tree_arena` in a separate lib
(but in the same workspace for now) - haven't thought of a good way to
make non root access not O(depth), without slowing down insertion or
using more memory, though have improved accessing nodes from the root to
O(1) from O(depth) and accessing direct children to O(1) from
O(children)
The biggest remaining issue in this PR is that IME support is not
present.
However, I think landing this is *better* than not landing it, because:
1) If we don't land it, it's going to languish again
2) Getting IME support back can be parallelised (cc @tomcur)
3) Getting Vello 0.3.0 and Parley 0.2.0 unlocks real advantages,
including full emoji support (#420).
To be clear, my first follow-up priority will be connecting the IME back
up. I do not however think this should block on Parley 0.3.0.
Discussion in
https://xi.zulipchat.com/#narrow/channel/317477-masonry/topic/Updating.20Parley.20dependency
If the alignment was set previously, and the `CrossAxisAlignment` was
not `Start`, the width Parley believed we were in wouldn't match the
width used for Masonry layout. This would lead to weird behaviour.
See the diff for the test images in
0a68159869
for more context
This is very useful for debugging performance issues. I've already used
it to debug [#masonry>`to_do_list`: Horrendous
performance](https://xi.zulipchat.com/#narrow/stream/317477-masonry/topic/to_do_list.3A.20Horrendous.20performance).
Setting a feature works on a workspace-wide basis. I.e `cargo run
--example mason --features tracy` works.
Some weirdness:
- Tracy seems to assume we know when a frame will "start", but we only
know if we'll repaint once processing for an event has finished.
- Something seems to be starting a default "Frame", which isn't really
right. We don't have any continuous frames. Maybe we should always
request a redraw if tracy is enabled.
Either way, I think this feature is useful to land *now*, so am not
planning on resolving these in this PR unless someone provides a
solution.
This example is inspired by:
https://troz.net/post/2024/swiftui-mac-2024/
Current status:
- Lists status code
- Can select status code
- Downloads image from status code
- Shows image from status code
This adds two new features to Xilem:
- The worker view, which is the obvious extension to `task` for multiple
operations
- The `image` view, which just uses Masonry `Image`.
It also fixes a the Masonry Image view's layout to use the already
extant but unused method.
- Adds tracing_android_trace
- Correct the span for VariableLabel
- Make the created apps "debuggable"
- Enable spans for `wgpu`'s `profiling` results
- Add a span around the Vello rendering to show when that is
This adds a new `VariableLabel` widget, which animates its weight to a
target value in a linear fashion (over a fixed time period). Also adds
support for this in Xilem, and a new `variable_clock` example. This
example also runs on Android.
[Screencast_20240812_171138.webm](https://github.com/user-attachments/assets/5df623f9-f4ca-4b55-b6a9-2047d2581b56)
Current status: The code in Xilem and Masonry library crates is final.
I'm planning on significantly updating the actual example.
Outstanding issues:
- [X] Hacks in support for "Roboto Flex", by always loading it from the
local file - resolved
- [X] It's not clear what subset of Roboto Flex we should use - still
open to bikeshedding
- [ ] The variable font animation support is not really as generic as it
should be. This starts to drift quite close to a styling question,
however.
- [ ] The only supported variable axis is `wgth`
Rather than have to keep a dependency on `kurbo` at the correct version,
always use it via `vello`.
This makes this match how `peniko` is already used within `masonry`.
See also linebender/vello#439
This should open the door to doing much more comprehensive testing at
higher level in the nearish future (including e.g. in `xilem_masonry`)
This is the `rerun_on_change` view described in #440, I named it
`MemoizedAwait` as I think that fits its functionality.
It got also additional features `debounce_ms` (default `0`) and
`reset_debounce_on_update` (default `true`) as I think that's quite
useful, in case a lot of updates are happening.
When `reset_debounce_on_update == false`, `debounce` is more a throttle
than an actual debounce.
This also adds a more heavily modified version of the example added in
#427, also showing `OneOf` in xilem_web (which didn't have an example
yet).
This *could* be considered as alternative to #440 (at the very least the
example) but those approaches could also well live next to each other.
---------
Co-authored-by: Markus Kohlhase <markus.kohlhase@slowtec.de>
There is one "semi-false-positive" lint triggered, which I have fixed.
Otherwise, the required
```
cargo upgrade --ignore-rust-version
cargo update
```
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.
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>
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>
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 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 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`.
`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.
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.
This brings in a lot of the old work from Druid and Masonry (prior to
linebender/masonry#56) on text, as well as some types from Glazier.
Needed work:
- [X] Text display using abstract types
- [x] Text selection with mouse
- [x] Text input with keyboard
- [ ] IME integration (of the kind winit understands)
Follow up work:
- [ ] Keyboard control of the selection area (hard-coded hotkeys)
- [ ] [Proper
placement](https://raphlinus.github.io/text/2020/10/26/text-layout.html#shaping-cluster)
of cursor
- [ ] Input methods
- [ ] Proper hotkey handling
- [ ] Copy and/or paste
Bruce Mitchener