Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add zstack view to compose views on top of each other #737

Draft
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

viktorstrate
Copy link
Contributor

@viktorstrate viktorstrate commented Nov 10, 2024

Adds a new zstack Xilem view (along with an accompanied Masonry widget).
The view is inspired by the ZStack view in SwiftUI, which composes the child view on top of each other.

This pull-request is still work-in-progress.

  • It doesn't allow for changing the layout when BoxConstraints of the children are different.
    (top-left, top-right, bottom-left, bottom-right, center).
  • I want to update http_cat to put copyright on top of image like seen below.
Screenshot 2024-11-10 at 17 46 45

@viktorstrate viktorstrate marked this pull request as draft November 10, 2024 16:28
@viktorstrate viktorstrate changed the title WIP: Add zstack view to compose views on top of each other Add zstack view to compose views on top of each other Nov 10, 2024
@Philipp-M
Copy link
Contributor

See also #591, which goes a similar direction.

I think to make a zstack really useful we would need transforms (kurbo::Affine) on widgets in general and relevant logic for pointer events etc. See also here. I'm thinking about getting to that topic soon, as I think this is the main blocker for allowing fancy interactive vector graphics with vello and xilem.

I like the general direction, i.e. unifying a potential xilem_svg API using a zstack (instead of separate context such as in the web).

@DJMcNab
Copy link
Member

DJMcNab commented Nov 11, 2024

I don't think that arbitrary transforms should block this landing, though. I don't really have the bandwidth to look at this too closely at the moment, unfortunately.

@Philipp-M
Copy link
Contributor

To clarify, I didn't mean this to be a requirement, it's orthogonal to this change (and a lot more work...). I'll take a look at the PR when it's out of draft. On a skim it seems reasonable so far.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants