Closed oakes closed 9 years ago
Thanks !
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.
@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.
@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
.
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 GType
s. If that is the case, couldn't we make separate enums? It seems like an important thing to have for safety and documentation.
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()
.
@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.
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 pullGType
fromglib_ffi
rather thangtk
, as that is where it originally comes from.