From a02821b48f0f56d95349c1ef86c7811ce68f1a63 Mon Sep 17 00:00:00 2001 From: Bruce Mitchener Date: Wed, 11 Sep 2024 23:43:06 +0700 Subject: [PATCH] Fix typos --- content/blog/2024-01-11-xilem-backend-roadmap.md | 4 ++-- content/blog/2024-06-15-rustnl-2024-unconference.md | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/content/blog/2024-01-11-xilem-backend-roadmap.md b/content/blog/2024-01-11-xilem-backend-roadmap.md index 842ab41..efaf987 100644 --- a/content/blog/2024-01-11-xilem-backend-roadmap.md +++ b/content/blog/2024-01-11-xilem-backend-roadmap.md @@ -132,7 +132,7 @@ Xilem's approach of "you own your children" is a little bespoke. It means the fr I believe Widgets should be owned by the library. If your container has children, then the only thing the container will actually own is keys into a structure (probably a slotmap) where the widget is stored. This makes a lot of things easier, like serialization and debugging, but it has an impact on the entire backend. It's an infrastructure investment. -Lately, I've seen more and more dicussion of implementing GUI through an ECS. A lot of that discussion comes from Bevy, which is natural, since the bevy community ~~is made up of ruthless cultists striving to feed ever more sacrifices to the ECS god until it consumes the Earth~~ is intimately familiar with the ECS pattern and has reached a phase where UI work is getting a lot of attention[^2]. But I've seen discussions about it in the Linebender community too. +Lately, I've seen more and more discussion of implementing GUI through an ECS. A lot of that discussion comes from Bevy, which is natural, since the bevy community ~~is made up of ruthless cultists striving to feed ever more sacrifices to the ECS god until it consumes the Earth~~ is intimately familiar with the ECS pattern and has reached a phase where UI work is getting a lot of attention[^2]. But I've seen discussions about it in the Linebender community too. Whether we actually want to use ECS is something we still need to research. @@ -144,7 +144,7 @@ GUI is pretty far from that ideal use-case: updates are sparse and should only r I think there are two things you really want from a Rust ECS library for GUI: slotmaps, and efficient ways to add and remove components from an entity. -Implementing those is going to be a major undertaking, which we'll have to divide into small experiements, but one I expect to pay many times over. +Implementing those is going to be a major undertaking, which we'll have to divide into small experiments, but one I expect to pay many times over. ## Community involvement and more to come diff --git a/content/blog/2024-06-15-rustnl-2024-unconference.md b/content/blog/2024-06-15-rustnl-2024-unconference.md index 403b8f0..0a67f4d 100644 --- a/content/blog/2024-06-15-rustnl-2024-unconference.md +++ b/content/blog/2024-06-15-rustnl-2024-unconference.md @@ -180,7 +180,7 @@ With that in mind, some notable sponsors for projects represented at the Unconfe - **Foresight Spatial Labs:** Bevy. - **Rerun.io:** egui. -Not present at RustNL but relevant to the ecosystem are **System76** (funding COSMIC-Text and contributing to iced), **Kraken** (funding iced), and **Slint** who are self-funding as a startup targetting embedded UIs and couldn't attend due to time constraints. +Not present at RustNL but relevant to the ecosystem are **System76** (funding COSMIC-Text and contributing to iced), **Kraken** (funding iced), and **Slint** who are self-funding as a startup targeting embedded UIs and couldn't attend due to time constraints. Overall the number of different backers feels like a symptom of a healthy ecosystem: while some large corporate sponsors bring much more resources than others (Google and Futurewei especially), the ecosystem isn't in a state where any specific backer pulling out would completely collapse progress.