jeremyletang / rgtk

GTK+ bindings and wrappers for Rust (DEPRECATED SEE https://github.com/rust-gnome )
GNU Lesser General Public License v3.0
121 stars 22 forks source link

Fix the gtktest and treeview examples #213

Closed oakes closed 9 years ago

oakes commented 9 years ago

This fixes two example projects that are currently broken. I also removed the get_gtype call from value.rs, as it seemed to break it. Lastly, I changed value.rs and gtype.rs to pull GType from glib_ffi rather than gtk, as that is where it originally comes from.

GuillaumeGomez commented 9 years ago

Thanks !

gkoz commented 9 years ago

If GType is a user exposed type, one shouldn't have to reach for it into the ffi. We might make an opaque wrapper to try and hide the fact that it's just a i32 isize. Until then I believe glib should expose it along with the other glib core types without any hoops.

oakes commented 9 years ago

@gkoz I agree, it was just a stopgap for now. Ideally, we eliminate glib_ffi::GType and only use the enum, gtk::GType. The main problem is that the enum variants are u32 while the actual GType is a u64, so you can't just pass the enum version to the naive functions and expect it to work. I haven't figured out the best way to deal with that. On Mar 1, 2015 6:41 AM, "Gleb Kozyrev" notifications@github.com wrote:

If GType is a user exposed type, one shouldn't have to reach for it into the ffi. We might make an opaque wrapper to try and hide the fact that it's just a i32. Until then I believe glib should expose it along with the other glib core types without any hoops.

Reply to this email directly or view it on GitHub https://github.com/jeremyletang/rgtk/pull/213#issuecomment-76593232.

gkoz commented 9 years ago

@oakes Right, it's isize not i32 or u64 -- one more reason we should not expose GType directly… The glib::translate infra from #211 could help with converting back and forth. But the type can't just be an enum because the set of types isn't fixed: each GObject descendant class (e.g. a widget) has a distinct GType.

oakes commented 9 years ago

OK, I thought it was a gulong but after looking at gtype.h again it appears that is only when it is compiled with C++:

#if     GLIB_SIZEOF_SIZE_T != GLIB_SIZEOF_LONG || !defined __cplusplus
typedef gsize                           GType;
#else   /* for historic reasons, C++ links against gulong GTypes */
typedef gulong                          GType;
#endif

I also wasn't aware that there were different GTypes. If that is the case, couldn't we make separate enums? It seems like an important thing to have for safety and documentation.

gkoz commented 9 years ago

Wow, is that confusing. But gulong likely still is a usize equivalent. Sorry, I was unclear earlier about different types. There's only one GType type of course and each class has a GType value that identifies it and that you get by calling e.g. gtk_window_get_type().

gkoz commented 9 years ago

@oakes Well actually GType can be an enum just fine, sort of like

enum Type {
    /// A boolean
    Boolean,
    /// A string
    String,
    // ...
    /// Other type identified by `GType`
    Other(ffi::GType),
}

But, if we step back and look at why GType is there in the first place we might find that GType and GValue have no business sticking out of the Rust layer. This library should arguably hide them behind a Rust-friendly interface. Designing a proper interface will take a lot of research though.