GNOME Bugzilla – Bug 642914
[gi] pass raw GValues instead of trying to marshal them
Last modified: 2011-02-22 19:04:18 UTC
* Right now GValues are transparent to the user but this leave us no way to describe fundimental types other than those supported directly by python (e.g. int, str, etc) * If an interface is expecting a uint or other GValue type a user can now use the raw GValue interfaces and expect paramaters that take GValues to marshal them correctly e.g.: value = GObject.Value() value.int(GObject.TYPE_UINT) value.set_uint(1234) * The objective here is to not for users to use this API but for overrides to be able to utilize them. For instance in the TreeModel API we can get the expected type for a column and them create a GValue with the correct type so that he underlying python object is marshalled correctly.
Created attachment 181520 [details] [review] [gi] pass raw GValues instead of trying to marshal them
See for an example of why we need this - https://bugzilla.gnome.org/show_bug.cgi?id=642921
Review of attachment 181520 [details] [review]: I'm lukewarm about adding GValue api. But it does make sense in certain circumstances and it makes the python bindings a bit more powerful. Even so, I'm not sure they should be used for overrides, why can't just pyg_type_from_object() be called appropriately when needed, as it was in pygtk? Or is this addition of GValue to the g-i api a way of rewriting a little bit larger chunk of the pygtk liststore/treemodel api in pure python? ::: gi/pygi-argument.c @@ +1015,3 @@ + GValue *src = (GValue *)((PyGObject *) object)->obj; + g_value_init (value, G_VALUE_TYPE (src)); + g_value_copy(src, value); This needs to be freed somewhere, it's AFACT a leak.
Check out the patch I linked to. pyg_type_from_object only returns a subset of types. This is how I rewrote the TreeModel code. GValues need to be exposed in order to use the value returned by get_column_type
(In reply to comment #4) > Check out the patch I linked to. pyg_type_from_object only returns a subset of > types. This is how I rewrote the TreeModel code. GValues need to be exposed > in order to use the value returned by get_column_type Looks reasonable, as long as it's transparent for normal PyGObject users.
Comment on attachment 181520 [details] [review] [gi] pass raw GValues instead of trying to marshal them committed with comments added about the lifecycle of the GValues