Crates.io | bevy_asky |
lib.rs | bevy_asky |
version | |
source | src |
created_at | 2024-12-08 10:12:10.502529 |
updated_at | 2024-12-11 12:02:48.63778 |
description | A simple question-and-answer UI middleware for Bevy |
homepage | |
repository | https://github.com/shanecelis/bevy_asky |
max_upload_size | |
id | 1476186 |
Cargo.toml error: | TOML parse error at line 18, column 1 | 18 | autolib = false | ^^^^^^^ unknown field `autolib`, expected one of `name`, `version`, `edition`, `authors`, `description`, `readme`, `license`, `repository`, `homepage`, `documentation`, `build`, `resolver`, `links`, `default-run`, `default_dash_run`, `rust-version`, `rust_dash_version`, `rust_version`, `license-file`, `license_dash_file`, `license_file`, `licenseFile`, `license_capital_file`, `forced-target`, `forced_dash_target`, `autobins`, `autotests`, `autoexamples`, `autobenches`, `publish`, `metadata`, `keywords`, `categories`, `exclude`, `include` |
size | 0 |
This library is intended to make asking questions of the user easier within an application built with Bevy. It is not intended to provide a comprehensive UI beyond question-and-answer, and may indeed be better thought of as scaffolding for whatever one's eventual UI may become.
[!WARNING]
bevy_asky
is currently in the early stages of development and is subject to breaking changes. The principle consumer of this crate is bevy_minibuffer, a gamedev console. As such it is under-developed for usage independent ofbevy_minibuffer
currently.
This crate uses a Model-View-Controller (MVC) architecture. Normally I am not too enthusiastic about MVC because there is a lot of ambiguity about what goes where especially when it comes to the controller aspect. However, I found that within Bevy's Entity-Component-Systems (ECS) architecture, MVC enjoys much clearer boundaries.
The models are all found in the bevy_asky::prompt
module. They represent the
data that is being manipulated.
The controllers are all implemented as systems and are not exposed to the user. If you prompt for a text field, and then hit 'a', the text field will append an 'a' character. It will not be shown though unless it has a view component.
The view handles presentation. One chooses which view by using a marker
component. There are two view modules in this crate: 'ascii' and 'color'. Their
marker components are ascii::View
and color::View
respectively.
One can use a view of their own. The configurability of these particular views are limited. It is suggested to copy-and-paste ascii.rs or color.rs for fine-grained control of the presentation.
commands
.construct::<Confirm>("Do you like cats?")
.construct::<ascii::View>(())
.observe(
move |trigger: Trigger<Submit<bool>>, mut commands: Commands| {
if let Submit(Ok(yes)) = trigger.event() {
commands.entity(trigger.entity())
.construct::<Feedback>(Feedback::info(if *yes {
"\nMe too!"
} else {
"\nOk."
}));
}
},
);
button::View
that uses mouse-clickable elements.There is old button code that used to do this, but it has rotted and no longer compiles.
bevy_asky | bevy |
---|---|
0.2.0 | 0.15 |
0.1.0 | 0.14 |
Thanks to Axel Vasquez for his excellent and inspiring asky crate.
[!NOTE] I originally tried to extend Vasquez's work from its terminal origin to work directly with Bevy. You can find that work in my fork, but it required a lot of compromises and pull requests needed on dependencies were not being accepted. So I decided to do a native-port of asky to bevy; this crate is the result.
This crate is licensed under the MIT License or the Apache License 2.0.