86d9592a3e
This: 1) Renames the current/old `xilem_core` to `xilem_web_core` and moves it to the `xilem_web/xilem_web_core` folder 2) Creates a new `xilem_core`, which does not use (non-tuple) macros and instead contains a `View` trait which is generic over the `Context` type 3) Ports `xilem` to this `xilem_core`, but with some functionality missing (namely a few of the extra views; I expect these to straightforward to port) 4) Ports the `mason` and `mason_android` examples to this new `xilem`, with less functionality. This continues ideas first explored in #235 The advantages of this new View trait are: 1) Improved support for ad-hoc views, such as views with additional attributes. This will be very useful for layout algorithms, and will also enable native *good* multi-window (and potentially menus?) 2) A lack of macros, to better enable using go-to-definition and other IDE features on the traits Possible disadvantages: 1) There are a few more traits to enable the flexibility 2) It can be less clear what `Self::Element::Mut` is in the `rebuild` function, because of how the resolution works 3) When implementing `View`, you need to specify the context (i.e. `impl<State, Action> View<State, Action, [new] ViewCtx> for Button<State, Action>`. --------- Co-authored-by: Philipp Mildenberger <philipp@mildenberger.me> |
||
|---|---|---|
| .. | ||
| examples | ||
| src | ||
| tests | ||
| .gitignore | ||
| Cargo.toml | ||
| LICENSE | ||
| README.md | ||
README.md
Xilem Core
Reactivity primitives for Rust
Xilem Core provides primitives which are used by Xilem (a cross-platform GUI toolkit). If you are using Xilem, its documentation will probably be more helpful for you.
Xilem apps will interact with some of the functions from this crate, in particular memoize.
Xilem apps which use custom widgets (and therefore must implement custom views), will implement the View trait.
If you wish to implement the Xilem pattern in a different domain (such as for a terminal user interface), this crate can be used to do so.
Hot reloading
Xilem Core does not currently include infrastructure to enable hot reloading, but this is planned. The current proposal would split the application into two processes:
- The app process, which contains the app state and create the views, which would be extremely lightweight and can be recompiled and restarted quickly.
- The display process, which contains the widgets and would be long-lived, updating to match the new state of the view tree provided by the app process.
Quickstart
no_std support
Xilem Core supports running with #![no_std], but does require an allocator to be available.
It is plausible that this reactivity pattern could be used without allocation being required, but that is not provided by this package. If you wish to use Xilem Core in environments where an allocator is not available, feel free to bring this up on Zulip.
Community
Discussion of Xilem Core development happens in the Linebender Zulip, specifically in #xilem. All public content can be read without logging in.
Contributions are welcome by pull request. The Rust code of conduct applies.
License
- Licensed under the Apache License, Version 2.0 (LICENSE or http://www.apache.org/licenses/LICENSE-2.0)