Open sanpii opened 3 years ago
After some investigation, here's what is happening:
gtk::main_quit()
ends the main loop.EventStream
's.Destroy
message in the EventStream
.I opened #267 with a fix. Can you test it please?
It works, it doesn't fix my real problem, but it's a good start :smiley:
Err, is your real problem related to relm
?
If so, what is it?
Err, is your real problem related to
relm
? If so, what is it?
I don’t know. The bugs appeared with the latest version.
The first one is due to an unowned widget: https://github.com/sanpii/effitask/commit/9fef741b5108a2de2eb2bafcc59e2c68f9828735
The second is still under investigation. This signal panics (Trying to call emit() on a dropped EventStream
) when I quit the application.
Yeah, those are a different issue and indeed caused by a bug that was fixed in relm
.
This is discussed in the blog post announcing this new version.
Basically, before version 0.21, the EventStream
's were leaked and thus, never dropped.
So, now you have to save the components somewhere, like you did in https://github.com/sanpii/effitask/commit/9fef741b5108a2de2eb2bafcc59e2c68f9828735 , so that they don't get dropped early.
It might not always be obvious how to fix it, but if you need more details about this change, please ask me.
By the way, I made this a panic!()
so that messages don't get silently dropped, but if you can think of a better solution, I'm all ears!
I rewrite the widget with multiple widgets view: https://github.com/sanpii/effitask/blob/logger/src/logger.rs
It’s cleaner! But still panic… I am going to write an simple application to reproduce this bug.
By the way, I made this a
panic!()
so that messages don't get silently dropped, but if you can think of a better solution, I'm all ears!
Logging an error, like gtk does with critical errors?
I thought about logging, but the log
crate won't log anything if the user don't use a logger, so that would should be logged with eprintln!()
.
Any reason why you prefer logging than a panic!()
? The panic gives you a stacktrace of where the error might come from, so I find it convenient.
A minimalist example to reproduce my bug:
Any reason why you prefer logging than a
panic!()
?
I don’t know if it’s a good idea to crash an application for a non-critical error. Ok, the corresponding action doesn’t work, but you expose users to corrupted data.
The panic gives you a stacktrace of where the error might come from, so I find it convenient.
Do both: panic in debug mode and log (with eprintln
if you prefer) in release mode?
In reality, it's just a problem the time it takes to update the application for relm 0.21.
Note to myself: it could be because of the handling of orphaned widgets.
The problem persist is a own the label:
diff --git i/src/main.rs w/src/main.rs
index 7019d65..0d8a592 100644
--- i/src/main.rs
+++ w/src/main.rs
@@ -33,11 +33,11 @@ fn main() {
#[relm_derive::widget]
impl relm::Widget for Logger {
fn init_view(&mut self) {
- let label = gtk::Label::new(None);
- self.widgets.list_box.add(&label);
+ self.widgets.list_box.add(&self.model);
}
- fn model() -> () {
+ fn model() -> gtk::Label {
+ gtk::Label::new(None)
}
fn update(&mut self, _: Msg) {
But disappear if I don’t use a popover widget:
diff --git i/src/main.rs w/src/main.rs
index 7019d65..1179b0c 100644
--- i/src/main.rs
+++ w/src/main.rs
@@ -44,17 +44,9 @@ impl relm::Widget for Logger {
}
view! {
- #[name="toggle"]
- gtk::ToggleButton {
- }
-
- #[name="popover"]
- gtk::Popover {
- relative_to: Some(&toggle),
- #[name="list_box"]
- gtk::ListBox {
- destroy(_) => Msg::Destroy,
- },
- }
+ #[name="list_box"]
+ gtk::ListBox {
+ destroy(_) => Msg::Destroy,
+ },
}
}
or simply don’t set its relative to:
diff --git i/src/main.rs w/src/main.rs
index 7019d65..c59f0b2 100644
--- i/src/main.rs
+++ w/src/main.rs
@@ -50,7 +50,6 @@ impl relm::Widget for Logger {
#[name="popover"]
gtk::Popover {
- relative_to: Some(&toggle),
#[name="list_box"]
gtk::ListBox {
destroy(_) => Msg::Destroy,
The Label
is actually not required to trigger this issue. If I remove the init_view()
function from the original code, it still panics.
The same program without relm: