This PR adds a basic grid layout to Masonry and Xilem.
The way this layout works is it has a fixed grid based on the initial
size passed in, and grid items are placed based on the position
requested. Grid items are allowed to span more than one cell, if
requested.
There are potential improvements that could be done, like the use of
intrinsic sizing for varied column width based on content size. Though
that could be done in the future taffy layout if we want to keep this
one simple.
~~This PR is still a draft because of one remaining concern. I was not
able to successfully optimize with conditional calls to child widgets
for layout. It led to crashes about the paint rects not being within the
widget's paint rect. `Error in 'Grid' #16: paint_rect Rect { x0: 0.0,
y0: 0.0, x1: 800.0, y1: 610.0 } doesn't contain paint_rect Rect { x0:
400.5, y0: 0.0, x1: 800.5, y1: 150.0 } of child widget 'Button' #5`. My
failed attempt at fixing it is commented out.~~
Since I am rusty on View Sequences, a lot of that code is based on the
Flex implementation. Let me know if I did anything incorrectly or if any
of it is unnecessary, or if anything is missing.
---------
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
Also improve documentation of pointer capture.
Continuation of 59ee615651
(https://github.com/linebender/xilem/pull/488).
Makes `has_pointer_capture` available on all context types except
`LayoutCtx`, like `is_active` used to be.
Recursing is done inside the paint and accessibility passes since
ff7635e4c2. I believe this is the correct
continuation of #522, with the removal of these methods "left for later"
as mentioned in
https://github.com/linebender/xilem/pull/522#issuecomment-2298610203.
One note is that Flex now debug-paints its baseline under its children,
rather than over them.
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`.
This is part of the "Pass Specification" RFC:
https://github.com/linebender/rfcs/pull/7
Rename WidgetCtx to MutateCtx.
Add a mutate pass.
Add a `mutate_later` context method to trigger that pass.
Refactor `edit_root_widget` to use a version of that pass.
Add a separate constructor for the synthetic WidgetState created in
RenderRoot.
---------
Co-authored-by: Philipp Mildenberger <philipp@mildenberger.me>
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
This is a first step in implementing the "Pass Specification" RFC:
https://github.com/linebender/rfcs/pull/7
Create a `passes` module.
Create event passes.
Create the update_pointer pass.
Remove `WidgetPod::update_hot_state` method.
Move mouse-cursor-handling code to update_pointer pass.
Implement pointer capture.
Refactor the TreeArena code.
---------
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
This pull request adds a simple calculator that can display binomial
math (ex: 2 + 2 = 4). Math operations with more than two operands are
done by moving the prior binomial results into the left operands.
This pull request also follows the existing convention by masonry's
calculator example to calc_masonry to differentiate them.
Let me know if there are any changes that I should make to improve code
quality.
<img width="404" alt="image"
src="https://github.com/user-attachments/assets/3498913b-dd4d-451c-8fa2-fcd2f7fd26af">
---------
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>
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).
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!
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`.
Olivier FAURE