Comments (11)
After some investigation, here's what is happening:
gtk::main_quit()
ends the main loop.- This triggers the destruction of the
EventStream
's. - There is still the
Destroy
message in theEventStream
. - This message is never sent to the component.
I opened #267 with a fix. Can you test it please?
from relm.
It works, it doesn't fix my real problem, but it's a good start
from relm.
Err, is your real problem related to relm
?
If so, what is it?
from relm.
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: sanpii/effitask@9fef741
The second is still under investigation. This signal panics (Trying to call emit() on a dropped EventStream
) when I quit the application.
from relm.
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 sanpii/effitask@9fef741 , 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!
from relm.
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?
from relm.
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.
from relm.
A minimalist example to reproduce my bug:
use gtk::prelude::*;
use relm::Widget;
#[derive(relm_derive::Msg)]
pub enum Msg {
Destroy,
Quit,
}
#[relm_derive::widget]
impl Widget for Win {
fn model() -> () {
}
fn update(&mut self, _: Msg) {
gtk::main_quit();
}
view! {
#[name="window"]
gtk::Window {
Logger {
},
delete_event(_, _) => (Msg::Quit, gtk::Inhibit(false)),
}
}
}
fn main() {
Win::run(()).expect("Win::run failed");
}
#[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);
}
fn model() -> () {
}
fn update(&mut self, _: Msg) {
}
view! {
#[name="toggle"]
gtk::ToggleButton {
}
#[name="popover"]
gtk::Popover {
relative_to: Some(&toggle),
#[name="list_box"]
gtk::ListBox {
destroy(_) => Msg::Destroy,
},
}
}
}
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.
from relm.
Note to myself: it could be because of the handling of orphaned widgets.
from relm.
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,
from relm.
The Label
is actually not required to trigger this issue. If I remove the init_view()
function from the original code, it still panics.
from relm.
Related Issues (20)
- Add CI for Windows and OS X
- Bad error message when misusing nested views
- Confusing error message on empty view! macro
- Why fragile crate is copy in src/vendor? HOT 2
- Comparison to vgtk HOT 1
- Can't run the examples HOT 2
- support for virtualized widget lists? HOT 4
- EventStream panics on emit from another thread HOT 1
- unexpected behavior of nested views in embedded separated component HOT 2
- relm's event don't work when in a busy loop in the gtk GUI thread even if calling process_events HOT 1
- How does one use relm with a TextView? HOT 2
- Create a new instance of a Relm widget HOT 2
- [RFC] Planning the transition to GTK4 (relm4) HOT 7
- 100% cpu use in Widget::run? HOT 1
- Broken description on crates.io HOT 1
- Dynamically create new widgets HOT 2
- Compilation error when using non-Copy types in messages HOT 7
- Nested view! macros use inner view as outer root HOT 1
- Make a clearer error message for View Macro
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from relm.