dnrops
/
xilem
mirror of https://github.com/linebender/xilem
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
xilem/Cargo.toml

59 lines
1.7 KiB
TOML
Raw Normal View History

Macro based implementation of xilem_core Experimenting with macros to make the View traits more generic.
2023-04-25 07:29:32 +08:00
[workspace]
Remove `xilem_classic` (#290) This can be accessed in the git history and has been replaced by the version using `masonry`.
2024-05-08 17:09:49 +08:00
resolver = "2"
Macro based implementation of xilem_core Experimenting with macros to make the View traits more generic.
2023-04-25 07:29:32 +08:00
members = [
Move `xilem` onto a new `xilem_core`, which uses a generic View trait (#310) 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>
2024-06-06 23:16:36 +08:00
"xilem",
Move crates to the repository root (#302) Follows the convention proposed in this discussion: https://xi.zulipchat.com/#narrow/stream/419691-linebender/topic/Standardizing.20multi-package.20repos
2024-05-12 05:59:03 +08:00
"xilem_core",
Move `xilem` onto a new `xilem_core`, which uses a generic View trait (#310) 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>
2024-06-06 23:16:36 +08:00
"masonry",
Move crates to the repository root (#302) Follows the convention proposed in this discussion: https://xi.zulipchat.com/#narrow/stream/419691-linebender/topic/Standardizing.20multi-package.20repos
2024-05-12 05:59:03 +08:00
"xilem_web",
"xilem_web/web_examples/counter",
"xilem_web/web_examples/counter_custom_element",
xilem_web: Add Elm Architecture example (#425) I have intentionally left out the `xilem_core::adapt` variant here in order to have a clear classic Elm example. I would rather show the `adapt` variant in a separate example.
2024-07-12 19:39:37 +08:00
"xilem_web/web_examples/elm",
Move crates to the repository root (#302) Follows the convention proposed in this discussion: https://xi.zulipchat.com/#narrow/stream/419691-linebender/topic/Standardizing.20multi-package.20repos
2024-05-12 05:59:03 +08:00
"xilem_web/web_examples/todomvc",
"xilem_web/web_examples/mathml_svg",
"xilem_web/web_examples/svgtoy",
Macro based implementation of xilem_core Experimenting with macros to make the View traits more generic.
2023-04-25 07:29:32 +08:00
]
Fill out and clean up all the `Cargo.toml` files. (#117)
2023-07-31 02:14:59 +08:00
[workspace.package]
edition = "2021"
Update to our latest CI standard (#414) This was most recently updated in https://github.com/linebender/vello/pull/505 The main differences are: 1) Greater concurrency between clippy and testing 2) More explanations 3) MSRV checking 4) Use of `cargo hack` 5) WASM checked in CI I've also added the current values of our MSRVs to the main three crates.
2024-06-28 21:02:54 +08:00
# Keep in sync with RUST_MIN_VER in .github/workflows/ci.yml, with the relevant README.md files.
Integrate `tokio` for async communication with Xilem (#423) Supercedes https://github.com/linebender/xilem/pull/411 This is designed with #417 in mind, to not lock-in to our event loop. --------- Co-authored-by: Philipp Mildenberger <philipp@mildenberger.me>
2024-07-18 15:38:28 +08:00
rust-version = "1.79"
Fill out and clean up all the `Cargo.toml` files. (#117)
2023-07-31 02:14:59 +08:00
license = "Apache-2.0"
Prepare `Cargo.toml` files for release. (#249) * Rename classic `xilem` to `xilem_classic` and the new `xilem_masonry` to `xilem`. No directory structure changes yet to avoid merge conflicts before RustNL. * Base common dependencies on workspace dependencies. * Bump `masonry` version to `0.2.0`. * Remove some legacy docs.rs configuration inherited from Druid/Glazier that is no longer needed. * Unify ordering of properties.
2024-05-04 04:07:12 +08:00
repository = "https://github.com/linebender/xilem"
homepage = "https://xilem.dev/"
[workspace.lints]
clippy.semicolon_if_nothing_returned = "warn"
Disable `clippy::assigning_clones` lint. (#331) Enabling [`assigning_clones`](https://rust-lang.github.io/rust-clippy/master/index.html#/assigning_clones) by default in Rust 1.78 was a mistake which was reversed in a week in [rust-clippy#12779](https://github.com/rust-lang/rust-clippy/pull/12779). We can disable it locally until the upstream fix arrives to stable Rust.
2024-06-03 22:35:03 +08:00
# Remove assigning_clones once it's allowed by default in stable Rust
# https://github.com/rust-lang/rust-clippy/pull/12779
Document masonry (#329) This was initially a supposed to be a small documentation pass, which grew into a few changes: - Adding back a to-do-list example. - Fixing the bugs revealed by that example (infinite bounding boxes, wrong accessibility handling in Portal, etc). - Making sure all widgets return the correct spans instead of the less-useful default one. - Adding a trace to the layout pass for easier debugging. Overall I'm pretty happy with this!
2024-06-03 22:21:41 +08:00
clippy.assigning_clones = "allow"
Differentiate pointer buttons in `Button` Widget and View (#397) In most cases, you want a button which only actuates when the primary mouse button is pressed, so the easy case is still that. This is a short term hack, because e.g. the active state is still based on any button being pressed, not just those we are interested in. That is, we probably need to represent a set of buttons we are interested in. However, this change minimally unblocks additional work with Xilem. In particular, see [#xilem > Minesweeper converted from Iced to Xilem](https://xi.zulipchat.com/#narrow/stream/354396-xilem/topic/Minesweeper.20converted.20from.20Iced.20to.20Xilem).
2024-06-15 00:40:26 +08:00
rust.unexpected_cfgs = { level = "warn", check-cfg = [
'cfg(FALSE)',
'cfg(tarpaulin_include)',
] }
Deny unsafe code globally (#406) Related to #44 We don't have any necessary unsafe code, and I don't think any of us want to lose that. (Vello is also no longer laundering the unsafety wrt surface creation thanks to a recent wgpu release)
2024-07-02 21:19:39 +08:00
# unsafe code is not allowed in Xilem or Masonry
# We would like to set this to `forbid`, but we have to use `deny` because `android_activity`
# requires us to use the unsafe `#[no_mangle]` attribute
# (And cargo doesn't let us have platform specific lints here)
rust.unsafe_code = "deny"
Fill out and clean up all the `Cargo.toml` files. (#117)
2023-07-31 02:14:59 +08:00
[workspace.dependencies]
Move `xilem` onto a new `xilem_core`, which uses a generic View trait (#310) 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>
2024-06-06 23:16:36 +08:00
xilem_web_core = { version = "0.1.0", path = "xilem_web/xilem_web_core" }
Move crates to the repository root (#302) Follows the convention proposed in this discussion: https://xi.zulipchat.com/#narrow/stream/419691-linebender/topic/Standardizing.20multi-package.20repos
2024-05-12 05:59:03 +08:00
masonry = { version = "0.2.0", path = "masonry" }
Move `xilem` onto a new `xilem_core`, which uses a generic View trait (#310) 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>
2024-06-06 23:16:36 +08:00
xilem_core = { version = "0.1.0", path = "xilem_core" }
Update to Vello 0.2.1 and wgpu 0.20.1 (#430) Mostly to double check that the new release is suitable, but formalising the update can't hurt
2024-07-17 15:42:20 +08:00
vello = "0.2.1"
wgpu = "0.20.1"
Bump kurbo and related dependencies. (#173)
2024-02-15 07:29:46 +08:00
kurbo = "0.11.0"
deps: Use workspace vello, release parley. (#238) `xilem` now uses the same `vello` as others (git for now) and everyone uses the new released version of `parley`.
2024-05-01 23:52:42 +08:00
parley = "0.1.0"
deps: Update `wgpu`, `vello`, `peniko` (#381) This brings us to the 0.2 release of Vello, which brings the 0.20 release of wgpu.
2024-06-10 16:29:53 +08:00
peniko = "0.1.1"
Update to winit 0.30.2 (#400) A fix was in winit 0.30.1 to fix a crash on exit on macOS (among other things). Fixes #239.
2024-06-16 15:14:04 +08:00
winit = "0.30.2"
Differentiate pointer buttons in `Button` Widget and View (#397) In most cases, you want a button which only actuates when the primary mouse button is pressed, so the easy case is still that. This is a short term hack, because e.g. the active state is still based on any button being pressed, not just those we are interested in. That is, we probably need to represent a set of buttons we are interested in. However, this change minimally unblocks additional work with Xilem. In particular, see [#xilem > Minesweeper converted from Iced to Xilem](https://xi.zulipchat.com/#narrow/stream/354396-xilem/topic/Minesweeper.20converted.20from.20Iced.20to.20Xilem).
2024-06-15 00:40:26 +08:00
tracing = { version = "0.1.40", default-features = false }
Prepare `Cargo.toml` files for release. (#249) * Rename classic `xilem` to `xilem_classic` and the new `xilem_masonry` to `xilem`. No directory structure changes yet to avoid merge conflicts before RustNL. * Base common dependencies on workspace dependencies. * Bump `masonry` version to `0.2.0`. * Remove some legacy docs.rs configuration inherited from Druid/Glazier that is no longer needed. * Unify ordering of properties.
2024-05-04 04:07:12 +08:00
smallvec = "1.13.2"
xilem,masonry: Use `dpi` crate directly (#320) This removes a class of dependencies from within both `masonry` and `xilem` on the `winit` crate where we can just use `dpi` directly instead. The `dpi` crate is meant (like `cursor_icon`) to be a shared ecosystem crate rather than only for usage with `winit`.
2024-05-29 15:52:04 +08:00
dpi = "0.1.1"
Prepare `Cargo.toml` files for release. (#249) * Rename classic `xilem` to `xilem_classic` and the new `xilem_masonry` to `xilem`. No directory structure changes yet to avoid merge conflicts before RustNL. * Base common dependencies on workspace dependencies. * Bump `masonry` version to `0.2.0`. * Remove some legacy docs.rs configuration inherited from Druid/Glazier that is no longer needed. * Unify ordering of properties.
2024-05-04 04:07:12 +08:00
fnv = "1.0.7"
deps: Update `image`, make workspace, turn off default features. (#279) The `image` crate has a number of dependencies which aren't needed in the core masonry crate, so we can turn off the default image format support and only enable "png" when used as a dev dependency. Also, make it a workspace dependency at the same time so that the version is only stated in a single location.
2024-05-07 20:57:55 +08:00
image = { version = "0.25.1", default-features = false }
masonry: Use `web-time` instead of `instant` (#323) Recently, `instant` has been marked as unmaintained by the maintainer. A suggested replacement is `web-time`, which is used by `winit` and is already in our dependency tree.
2024-06-03 19:30:55 +08:00
web-time = "1.1.0"
Update dependencies. (#283) These are the results of running ```sh cargo upgrade --ignore-rust-version cargo update ``` in preparation for the upcoming release. These are semver compatible updates.
2024-05-08 03:38:40 +08:00
bitflags = "2.5.0"
[masonry] Update to accesskit 0.16 (#426) There was a breaking change in this release that renamed `role::StaticText` to `role::Label`.
2024-07-16 16:18:51 +08:00
accesskit = "0.16.0"
accesskit_winit = "0.22.0"