lvgl
Samples fail on master due to error interface mismatch
In the process of running sample. I fail on Master, while they works on tags/0.6.2.
Compiling lvgl v0.6.2 (/home/fulup/Workspace/Tux-Evse/lv_binding_rust/lvgl)
error[E0277]: the `?` operator can only be applied to values that implement `Try`
--> lvgl/../examples/demo.rs:44:5
|
44 | screen.add_style(Part::Main, &mut screen_style)?;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the `?` operator cannot be applied to type `()`
Interfaces for functions like add_style changed. On master they changed and to stop returning LvResult<()>
fn add_style(&mut self, part: Self::Part, style: &'a mut Style) {
unsafe {
lvgl_sys::lv_obj_add_style(
self.raw().as_mut(),
style.raw.as_mut() as *mut _,
part.into(),
);
};
}
Oops, had kind of left this codebase mid-rework before I got distracted by work. I'll fix up the examples in a minute. Thanks!
No problem, I understand keeping sample up to date is never simple. By the way, when entering the project it is not easy to guest samples expected behavior. A PNG of expected result for each sample would help.
In my case demo+button works but App+Meter do not start any graphics. (OpenSuse-15.4 / Rust 1.71), normal ?
fulup@fulup-desktop:~/Workspace/Tux-Evse/lv_binding_rust> DEP_LV_CONFIG_PATH=`pwd`/examples/include cargo run --example meter --features
="alloc embedded_graphics"
Finished dev [unoptimized + debuginfo] target(s) in 0.15s
Running `/home/fulup/.cargo/build/debug/examples/meter`
Currently broken :c
The meter example has been broken for a while since the move to LVGL 8 entirely rewrote its API - look at the last line of the log you sent. I'll try to get the others fixed (and put some images of expected output) by the end of the day, though
Thank you for your reactivity. I'm currently rebuilding "arc.rs" sample out of tree. Using your work out of tree also would deserve a small explanation in the README, or even better an external git repo for samples as https://github.com/embedded-graphics/examples
Following cargo.toml works, but is it optimal ?
[features]
default = ["embedded_graphics","alloc"]
embedded_graphics = ["embedded-graphics"]
alloc = ["cstr_core/alloc"]
[dependencies]
lvgl = "0.6"
lvgl-sys = { version = "0.6"}
embedded-graphics = { version = "0.7.1", optional = true }
cstr_core = { version = "0.2.6", default-features = false, features = ["alloc"] }
embedded-graphics-simulator = "0.4.0"
[[bin]]
name = "lvgl-arc"
path = "src/lvgl-arc.rs"
required-features = ["alloc", "embedded_graphics"]
For lvgl dependencies, just use the latest git. 0.6 was a fair bit ago and there have been a lot of bugfixes since. Also, you (hopefully) won't need lvgl-sys unless you're dipping into unimplemented features. Otherwise this seems perfectly fine, yeah
version number: In fact giving 0.6 as dependencies pull the latest 0.6.x version. As today the 0.6.2. As we target production and not development, we are willing to make sure that if a minor version is publish we try it. When our code break with new version of a package, we like to known it as soon as possible.
lvgl-sys is use by arc.rs sample as well as by demo.rs. In 1st case to get memory consumption and for the second looks like to get a font. But I understand your point, it is not sure that I will need it for my final application.
fn mem_info() -> lvgl_sys::lv_mem_monitor_t {
let mut info = lvgl_sys::lv_mem_monitor_t {
total_size: 0,
free_cnt: 0,
free_size: 0,
free_biggest_size: 0,
used_cnt: 0,
max_used: 0,
used_pct: 0,
frag_pct: 0,
};
unsafe {
lvgl_sys::lv_mem_monitor(&mut info as *mut _);
}
info
}
DEP_LV_CONFIG_PATH= Hopefully last point about boot strapping out of tree.
Is there a way to hide lv_conf.h path somewhere (build.rs, cargo, ...). I would rather get a vanila "cargo build" command and not as today in my case DEP_LV_CONFIG_PATH=`pwd`/lvgl/config cargo build
Arbitrary env vars can be specified in .cargo/config.toml; a branch to specify a rust-native config format exists but is very early in development and I haven't had much time to work on it in a bit unfortunately.
Arbitrary env vars can be specified in
.cargo/config.toml; a branch to specify a rust-native config format exists but is very early in development and I haven't had much time to work on it in a bit unfortunately.
I understand, and furthermore it remains a "nice to have" feature and nothing critical.
Thank you again for your support.
If anyone else gets bitten by this, I (know 0 Rust, but) was able to resolve the issue by removing the ?s from the ends of the lines where it's complaining.
If anyone else gets bitten by this, I (know 0 Rust, but) was able to resolve the issue by removing the
?s from the ends of the lines where it's complaining.
Same, I've opened #183 with this fixes
Most of the pull requests that fixed examples are now merged, can we close this issue?