JeremyLetang/rgtk — pull request #5 by Blei (2013-12-15 20:17:17+00:00)
Title: RFC: Signals redux

First off: this is an RFC, not the final implementation. I don't expect this to be merged in its current state.

I've tried to implement the proposed signal handling method for the Window type. As you can see, this requires dozens upon dozens of signals with different signal handler traits. And because most of them are actually in GtkWidget, these functions/methods and traits will have to be duplicated for dozens upon dozens of types... You were right, I'm no longer sure if this will work out, i.e. if it is worth the effort and at least somewhat maintainable.

IMO there are 4 ways to go forward with this:
* Scrap it and think of a better way to handle signals
* Keep on adding stuff as has been done with Window, try to find some clever macros to make it a bit faster
* Make it at least a bit easier to write and maintain by moving these signals and traits to the GtkWidget trait instead. This will mean that the handler methods won't have exact information about the types they are passed though (they will always get a Widget for signal that are defined on GtkWidget). This would mean that some kind of casting operations would have to be added, e.g. something like `trait GtkWidget { fn as_window(&self) -> Window { GtkWidget::wrap_widget(cast_GtkWindow(self.ptr)).unwrap() } }` (I think some kind of casting will be needed if we take this option or not, as some of the signals have GtkWidget pointers as data where we can't statically know the actual type, but the user might).
* Instead of writing everything ourselves, use the GObject introspection XML files and write some code generation tool

I really don't know which way is the best here... What do you think?