Closed oakes closed 9 years ago
We need GType
to support other types too. FromPrimitive
doesn't cut it. Why u64
? Is GType
64 bit long on i386
?
I can draft up my version of the gtype patch later today.
The tree and list widgets could at least use some variant enum, that would hide all the gtype trickery. Need to take some time and think how to do it.
I don't know what other types you are referring to. GType is a finite collection of constants defined in gtype.h. I also do not know what it is on i386, but isize was not working when I tried it. The GTK docs are pretty horrible and haven't helped in understanding that. On Mar 5, 2015 8:51 AM, "Gleb Kozyrev" notifications@github.com wrote:
We need GType to support other types too. FromPrimitive doesn't cut it. Why u64? Is GType 64 bit long on i386? I can draft up my version of the gtype patch later today.
The tree and list widgets could at least use some variant enum, that would hide all the gtype trickery. Need to take some time and think how to do it.
Reply to this email directly or view it on GitHub https://github.com/jeremyletang/rgtk/pull/223#issuecomment-77366454.
GType
certainly is not a finite collection of constants. Every class in the GObject
paradigm is identified by its own GType
value and every instance carries its type value as well. There are uses for GType
in GTK outside of GValue
, like requesting a list of widgets of a particular type.
I'm talking specifically about fundamental types. I don't see how we can support arbitrary derived types in a C-like enum.
My GType
patch is #225
Note that C-style constants go into the -sys
module and then are used elsewhere.
Since glib::translate
has been merged it should be the unified way to convert between Rust and native types. It will allow for generic implementations of some of treeview methods that could just take T: ToValue
(ToValue
implemented for String
and numeric types) and not make the user put in the types by hand every time.
This is the same as #221 but moves GType to the glib crate and replaces
as u64
withas ::glib_ffi::GType
for better maintainability. I don't know how to get the variant working as @gkoz mentioned.