After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 642914 - [gi] pass raw GValues instead of trying to marshal them
[gi] pass raw GValues instead of trying to marshal them
Status: RESOLVED FIXED
Product: pygobject
Classification: Bindings
Component: introspection
unspecified
Other All
: Normal normal
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
Depends on:
Blocks: 642921 642922
 
 
Reported: 2011-02-21 21:21 UTC by johnp
Modified: 2011-02-22 19:04 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
[gi] pass raw GValues instead of trying to marshal them (3.50 KB, patch)
2011-02-21 21:21 UTC, johnp
committed Details | Review

Description johnp 2011-02-21 21:21:50 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.
Comment 1 johnp 2011-02-21 21:21:52 UTC
Created attachment 181520 [details] [review]
[gi] pass raw GValues instead of trying to marshal them
Comment 2 johnp 2011-02-21 22:31:09 UTC
See for an example of why we need this - https://bugzilla.gnome.org/show_bug.cgi?id=642921
Comment 3 Johan (not receiving bugmail) Dahlin 2011-02-21 22:58:07 UTC
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.
Comment 4 johnp 2011-02-21 23:22:19 UTC
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
Comment 5 Johan (not receiving bugmail) Dahlin 2011-02-22 01:13:23 UTC
(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 6 johnp 2011-02-22 15:56:45 UTC
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