This PR adds another widget to the widgets example, and also draws boxes
around each widget to separate them visually. I wanted to use flex wrap
to display them, but I don't think that's implemented yet in Xilem, and
the layout I did use isn't bad.
It also provides a simple example of the use of `Adapt`
---------
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
This is part of the Pass Specification RFC:
https://github.com/linebender/rfcs/pull/7
---------
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
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.
This is part of the Pass Specification RFC:
https://github.com/linebender/rfcs/pull/7
Note: This PRs comes with a lot of new TODO items. Addressing most of
these items is difficult without major refactors, because Portal code
deals with accessing values across multiple widgets, which is still hard
to do elegantly.
Fixes#576
Can someone who's more familiar with Masonry please confirm that I'm
doing this the right way? I assume that one is supposed to call
request_accessibility update along with request_paint whenever the
change to the widget state could affect accessibility.
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.
@PoignardAzur I wanted to have a play with masonry, so I had a go at
building a progress bar. I've made a PR in case you want it, but I won't
be offended if you close the PR. I'm happy to make changes if you see
anything you'd like to change.
---------
Co-authored-by: Olivier FAURE <couteaubleu@gmail.com>
Co-authored-by: jaredoconnell <jared.oc321@gmail.com>
This is also added to `variable_clocks` as needed.
This could also be added to `mason`, but I see a worrying amount of lag
if I do...
I could do with some help tracking this down.
Fixes https://github.com/linebender/xilem/issues/559
See comment on the fix for an explanation. Essentially, the `major`
value was used for multiple purposes, and this corrects into the
expected "direction".
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.
The `SizedBox` widget in Masonry had the option to set a background
brush that was not exposed in its corresponding view in Xilem. The
`SizedBox` view now exposes the option.
Incidentally, `BackgroundBrush::PainterFn` variant had the wrong type,
as such it was not usable. A `scene` parameter is added and the closure
now requires to be `Send + Sync`.
---------
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
Unfortunately this lint is very conservative in its detection, it hasn't
detected the other fix in this PR...
I manually checked, if we had any other bitwise or/and for booleans, and
indeed this was the only case.
---------
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
- 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
One of the problems we ran into with the `to_do_list` example was that
we had a `Flex` inside a `Portal`: the `Portal` widget is designed to
display scrollbars and provide scrolling if the child is larger than its
constraints... but then Flex's `layout` method always clipped the
returned size so it wasn't ever larger than its constraints. Hence, no
scrolling. Removing the `bc.constrain(my_size)` part makes the example
have scrolling behavior again.
This PR also tweaks scrolling code and adds `#[track_caller]` attributes
to help with debugging.
---------
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
I opened https://github.com/linebender/xilem/issues/473 earlier today,
but I realized after looking at the code that it would be super simple
to implement!
Copying over some context from that issue:
- I'm working on a graph renderer using Vello.
- I'm porting it over to a Masonry widget, so that I can build a UI
around it.
- In doing so I noticed there wasn't support for winit's `PinchGesture`,
which I had been using before when messing around with this on my macOS
device.
Please let me know if y'all feel like this is appropriate to include
inside of `PointerEvent`!
Spencer C. Imbleau