How can I help?

[axelkar]

https://linebender.org/blog/xilem-2024/

For those who are interested, you are invited to come build this future with us.

• What state is this repo in right now?

• First thing I found while skimming through the code is that Button uses a String.

  1. Is it possible to use borrowed values in the tree? :D Or would you need self-referential types?
  2. What about &'static str?
  3. How hard would it be to substitute that with a "generic widget type"? Generics? dyn Trait? dyn Trait in a library-provided type?
  4. Here's how GPUI does it (although GPUI doesn't have such high-level components like buttons but bases most things around a div element along with a large styling system and shared/generic interactive code):
     
     

• xilem/src/view/taffy_layout.rs

  Lines 128 to 136 in 072358e

  	if self.background_color != prev.background_color {
  	element.background_color = self.background_color;
  	flags |= ChangeFlags::PAINT;
  	}
  	if self.style != prev.style {
  	element.style = self.style.clone();
  	flags |= ChangeFlags::LAYOUT | ChangeFlags::PAINT;
  	}

  
  Why isn't the background color in style?

• Why isn't taffy a central part of Xilem? Seems like

• For styles in general, I recommend y'all to check out GPUI (apologies for the screenshots but gpui doesn't have a rustdoc anywhere on the internet)

• How are pointer events handled? Binary search? Loop over each leaf node? Loop over every node in the tree? Do they work with overlapping elements like modals, dropdowns, etc.?

• https://github.com/linebender/rfcs/blob/main/rfcs/0001-masonry-backend.md
  Has the work on this begun?

[DJMcNab]

Thanks for your interest. I would encourage you to join the Zulip at https://xi.zulipchat.com. You would be welcome to join the office hours, which happen weekly. Details can be found in the #office-hours stream

This repository is in an intermediate state - as you noted, the move to masonry is planned, and the work towards that is in-progress (see #masonry > Porting Masonry to Vello).
It's unfortunately hard to have significant contributions until that work is complete.

Button is unable to use a borrowed value, because there are always two Views living at the same time, the current moment's and the next moment's. In between these, we need to have mutable access to the app state, which means that the "current" borrowed str would become invalid. I don't think we've looked into alternatives at the moment. I wouldn't be surprised if we settled on Arc<str> or something very similar to that SharedString type.

In terms of embedding a widget within a button, which I think is what you're asking?
That should be possible, but would probably not be type erased, and would probably use generics.

I think background colour is not in style, because style only cares about the layout properties provided by Taffy. I haven't dug into it, however

Why isn't taffy a central part of Xilem? Seems like

I'm not clear where the sentence fragment is leading here. I think we're still evaluating options for layout, but Taffy is the most likely candidate. However, I don't think we want to force every widget to use it, if possible.

GPUI's giant style struct might not line up very well with the incremental updates Xilem is aiming to use, but I haven't dug into it very far.

I'm not sure how pointer events handled.

[axelkar]

Thanks for the info! May I ask why generics are used instead of type erasure? Won't it increase compile times?

[Philipp-M]

Won't it increase compile times?

Not necessarily. In general it's often the case though. It's probably weighing between advantages of static analysis and slightly faster compile times. From my experience it's not too bad when avoiding issues like rust-lang/rust#105900, I think e.g. chumsky and warp suffers from that. IMO the advantage of static analysis is a better trade-off though, since incremental compilation already makes this quite bearable (as I think hot-reloading is the main motivation to keep compile-times low). Also since the reactive layer (View) is separated from the lower stack, this is likely less of an issue.

GPUI's giant style struct might not line up very well with the incremental updates Xilem is aiming to use, but I haven't dug into it very far.

The more I think about it, the more I'm inclined towards using ECS for style attributes (and will probably start some experimentation on that soon with bevy-ecs)

Anyway OT, this should probably continue on zulip...