[RFC] GObject wrappers refactoring

[gkoz]

Do not merge!

Here's my latest and likely final (modulo small improvements) version of the GObject wrapper framework first proposed at jeremyletang/rgtk#197 that's supposed to replace the current approach of using macros and a C glue module.

Objectives:

• reduce code duplication by encapsulating reference counting and containers management;
• reduce boilerplate by factoring out most common conversions and checks;
• reduce reliance on macros in favor of generic programming that allows better type checking;
• improve support for implementing multiple interfaces (e.g. GtkTreeModel is an interface implemented by GtkTreeStore, it shouldn't be represented as a separate widget);
• support implementing some widgets in separate crates (e.g. libvte);
• remove the need for gtk_glue.c and build complications it brings;
• move toward automatic code generation from GIR by unifying the translations to/from the FFI types.

The glib::translate module shows all its power now: you can have a string, a widget, a nullable widget or a GList of widgets, doesn't matter, it just works, all applicable asserts included:

    pub fn new() -> Button {
        unsafe { Widget::borrow_from_glib(ffi::gtk_button_new()).downcast_unchecked() }
    }

    fn get_name(&self) -> Option<String> {
        unsafe {
            from_glib_none(ffi::gtk_widget_get_name(self.upcast().to_glib_none().0))
        }
    }

    fn set_name(&self, name: &str) {
        unsafe {
            ffi::gtk_widget_set_name(self.upcast().to_glib_none().0, name.to_glib_none().0)
        }
    }

    fn get_ancestor(&self, widget_type: Type) -> Option<Widget> {
        unsafe {
            from_glib_none(
                 ffi::gtk_widget_get_ancestor(self.upcast().to_glib_none().0, widget_type.to_glib()))
        }
    }

    fn get_children(&self) -> Vec<Widget> {
        unsafe {
            Vec::from_glib_container(
                ffi::gtk_container_get_children(self.upcast().to_glib_none().0))
        }
    }

The basic example (not present in this PR) demonstrates the use of the only two widgets supported in this proof of concept - Window and Button each implementing its own trait as well as WidgetTrait and ContainerTrait, and downcasting from Widget to Button.

The changes touch almost all crates, you can find the principal changes here: glib, gtk, examples but for the example to build other crates need patching too.

If you want to run the code I suggest using the git-repo tool:

• Install repo.
• Set up the working copy:

> cd some_empty_dir
> repo init -u https://github.com/gkoz/rust-gnome-manifest -b refactor_objects
> repo sync

• Run:

> cd examples
> cargo run

[GuillaumeGomez]

The biggest current problem is the fact we can't convert an object into another one. For example, converting a GtkListStore into a GtkTreeModel. I wanted to add two functions for this:

trait GObject {
    pub fn cast_to<T: GObject>(&self) -> T;
    pub fn cast_from<T: GObject>(object: &T) -> Self;
}

Your solution seems to allow such a thing in a better way. I'll test your example by the end of the week but I think I'll appreciate it. Very nice job !

[gkoz]

I've now changed the FromGlibPtr/ToGlibPtr methods to avoid possibly confusing ownership terminology and use the transfer: none/container/full convention from GIR and gnome docs.

[gkoz]

I've started implementing the conversion. The progress can be reviewed here: https://github.com/gkoz/rust-gnome-gtk/tree/object_reform

[GuillaumeGomez]

Okay, I'll look it this week-end. Thanks for your work ! =D

[gsingh93]

What's the status of this?

[gkoz]

I've been somewhat distracted by other stuff including rustdoc (gtk-rs/gdk#49) but this is in progress.

[gsingh93]

What do you think of merging just the object.rs file and letting any new widgets I add use the new framework? I think that works better than me adding new objects using the old framework or sending pull requests to your work in progress branch.

There would be a bit of inconsistency between previous and new widgets, but I don't think that's a big deal.

[gkoz]

We could merge that file but without cooperation from numerous traits that may not be enough. You can't use the widget unless it implements FFIWidget and WidgetTrait and some of the traits are implemented with macros... Straightening all that out takes away time from the refactoring.

[gsingh93]

Hey @gkoz, any update on how this is going? I saw the work going on with GIR and generating bindings, any update on that?

[GuillaumeGomez]

@gsingh93: @gkoz is finalizing it, he said it should be done in a few days/weeks. I'll bring my help on this once I'm back from holidays to speed it up.

[gkoz]

@gsingh93 this is mostly done (with the majority of bindings autogenerated thanks to great work by @EPashkin). I've been swamped with other stuff lately but will catch up soon.

[gkoz]

The implementation is at #221.