Closed osa1 closed 9 years ago
To clarify the alternative approach, here's a concrete example. GtkTreeView doesn't signal Clicked
but we can still connect a Clicked
handler to it. Using this trait-based approach, we can prevent this by not implementing Signals<Clicked> for TreeView
.
The problem with this approach is that we'll need to implement huge amounts of trait implementations. Maybe current approach is better for simplicity.
Hey, the current code is correct for me.
I think too, the second approach will be better. Just one thing, I think that Connect
will be more appropriate instead of Signals
for the trait name.
A simple macro will allow us to generate the implementation easily.
Just a simple example for the macro:
#![feature(macro_rules)]
struct Widget;
struct Clicked;
struct Pressed;
struct NotSignal;
pub trait Signal {}
impl Signal for Clicked {}
impl Signal for Pressed {}
pub trait Connect<S> {
fn connect(&self, s: &S);
}
macro_rules! impl_connect(
($struct_name:ident -> $($signal_name:ident),*) => (
$(impl Connect<$signal_name> for $struct_name {
fn connect(&self, s: &$signal_name) {
println!("signal connected !");
}
})*
);
)
impl_connect!(Widget -> Clicked, Pressed)
Just tells me what you want to do !
You're right that we can use macros to make the job a lot easier.
Still, I say let's merge this for now, and work on refactoring like that later. We can open an issue to keep track of progress on implementing trait-based approach.
(The problem is that I need to work on my application and I don't want to spend a lot of time on bindings for now, as long as it provides me functions I need ..)
Okay no problem! so il will work on this tonight if I have time. Just by curiosity you're application is open source / on github ?
Thanks.
My app is not open source yet, but it'll eventually be open source.
Resolves #118.
All examples are working.
There's also another way of handling this. We can have something like this:
and implement this for every type. I think this is a bit better because it allows us to have more precise types, for example, we can't connect a callback to a signal that the object won't fire. If you like this idea I think I can implement.