This is a very messy, very basic skeleton of what Masonry documentation
will eventually look like.
Main points are:
- Dedicated documentation modules.
- Re-using most of the language from the RFCs.
Next steps are:
- Flesh out the Widget documentation.
- Rewrite all those docs in a less placeholder-y way.
- Add chapter about the widget arena.
- Spread out that pass documentation to the respective pass files.
- Rewrite ARCHITECTURE.md.
- Add screenshots.
Fixes#376 and #389.
---------
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
See discussion here https://github.com/linebender/xilem/pull/663 and [on
zulip](https://xi.zulipchat.com/#narrow/channel/317477-masonry/topic/Improving.20docs.20for.20WidgetMut).
Basically, previous code was using `WidgetMut<MyWidget>` as a receiver.
This can be done when WidgetMut is a local type, but external users
wouldn't be able to do it. The result would be that users importing
Masonry as a dependency but copy-pasting code from one of our widgets
would get compile errors.
This PR switches to a syntax that external crates will be able to use
when declaring widgets. It's a more verbose, less readable syntax, but
it's unambiguous and doesn't require clever tricks.
We can consider switching back to WidgetMut-as-a-receiver when
`#![feature(arbitrary_self_types)]` or some equivalent gets stabilized.
See
https://github.com/rust-lang/rust/issues/44874#issuecomment-2122179688
for current progress.
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 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>
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>
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.
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).
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!
Olivier FAURE