Xilem architecture prototype #2183
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is similar to lasagna but with strongly typed elements. Let's see how it goes.
Support for type erasure of views and widgets.
Bring in more widget tuples with a macro.
Event propagation has no mutable access.
This passes the app state down through an Rc using a lens-like construction. I'm not sure this is the best construction. Perhaps it should be combined with adapt (the callback could take both mutable state references), but that's 3 callbacks. Also makes state mutable in event propagation, which seems useful.
Also trying out a few more node types in the example.
Fix very small typo
Use xdg-desktop-portal's dbus APIs for open/save dialogs on x11.
This commit was derived from the async experiment, which required adding a waker to the reconciliation context. We will definitely be adding more things to Cx so that should be the type of View methods, but also we'll iterate a while on the core architecture before re-introducing async. Note, it also bounds the element type for View to Widget, which is less flexible but more ergonomic.
Provide default (unit) action type for View. Add with_id and with_new_id methods to Cx which ensure proper nesting by construction.
Tweak signature of rebuild method to return a boolean indicating whether anything has been changed. This is not used yet, but will be for invalidation.
Let event handlers do different things than return user-specified actions. This may not be used immediately but is important for implementing environment.
The prototype had an extremely skeletal implementation of the widget hierarchy, but with this commit we start building more of a real one. It's based to a large exttent on existing Druid widgets, but some parts may be done differently, in particular an exploration into layout more similar to SwiftUI.
Add some layout methods. Rename Column to VStack. Put in alignment mechanisms. Much of the core layout protocol is implemented, but it's not exercised very deeply. A lot of view wrappers like "frame" in SwiftUI need to get implemented. I think I want to get the core widget trait more or less stable first (events need work in particular).
Adds axis to SingleAlignment (renamed from OneAlignment). Incorporates layout offsets into alignment results.
In SwiftUI, HorizontalAlignment.center and VerticalAlignment.center are two different structs, but in Rust it's just as convenient, if not more so, to let the same struct just impl the two different traits.
This brings the event method in line with other widget methods, and also existing Druid. Also adds mutable access to the event queue to the base context state, so other contexts can add events. This will be useful for LayoutObserver (event generated from layout context). Actual event propagation is still very under-developed, but it should be possible to build that out without big signature changes.
Implement the "layout observer" concept which is very similar to GeometryReader in SwiftUI. Also fix some problems in vstack layout computation.
Move relevant bits into core and contexts files, mirroring the structure of existing Druid (which hopefully will make it easier to navigate when adapting existing Druid code to the new architecture).
The widget set really should be structured as a library, and it will no doubt be useful to have multiple examples to exercise various aspects of that. This patch changes from a single main executable to a library with an examples dir.
I've decided on the name "xilem" rather than "idiopath," and this also matches the blog post (now linked from the README, though that is a bit stale).
Import some of the event dispatching logic from Druid. Still fairly minimal, not yet doing real hot/active logic on buttons yet (doing it the same way as Druid would depend on adding lifecycle to the Widget trait).
Add the lifecycle method to the Widget trait, matching existing Druid. I'm not at all convinced it's necessary - in original Druid, one of the main differences is that it doesn't have mutable access to app state, but that concern isn't really relevant. In any case, this minimizes divergence, and can possibly be cleaned up later.
This commit implements the core functionality of button, including hot/active states, drawing of appearance, and reasonable layout. There are other changes in widget infrastructure to support this functionality.
|
Two months on, the peanut gallery wonders what impressions/experiences Druid developers and/or users have had with this prototype. Is the mood optimistic? Have unexpected challenges arisen? I hope this doesn't come across as "are we there yet" — I'm actually just maddeningly curious about what people think about it! 😅 |
|
I didn't get the impression that this is in the state where it can be tried out easily, since there was no call for testing or similar. |
Nice to see that this idea caught on. You can copy my code for compressed paths if you like, though they may be less useful for Xilem since you have separate In general I like this idea quite a lot. Some comments:
Xilem has inspired me to consider something vaguely similar built on top of KAS, which could go some way to solving its biggest weaknesses (difficulty expressing dynamic layout, and not requiring manual updates of widgets dependant on app state). But if we're honest, the Rust UI space is a lot more crowded today than it was when these projects started. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I am writing a blog post on the Xilem architecture, and want that to refer to a PR, as that is the most stable identifier for a branch; the PR can be closed and the branch deleted, and still resolve.
I will also continue to explore and develop in this branch. We might rethink that if we start developing more collaboratively.
Also note, I do the same with the idiopath_py and idiopath_async branches. Those are shorter-term explorations, and basically I just want to capture what I did. It's likely the ideas for both will get merged into this branch.