* this is so we can support sending Gdk.Event members in place of the Event union into methods * we only support this if the union member has a type of GI_INTERFACE for now https://bugzilla.gnome.org/show_bug.cgi?id=659879
…t init stage" This reverts commit f6fa5dd.
…ert* apis * in python 3 len(str) returns the number of characters while the length parameter is expecting the number of bytes. It also excepts -1 for null terminated string. Since all of our strings are null terminated, just set length to that.
This used to be provided for backwards compatibility with older PyGTK versions. As PyGObject3 no longer provides support for static bindings like PyGTK, the pygtk_version attribute has become obsolete. https://bugzilla.gnome.org/show_bug.cgi?id=659142
* having the variable in the .pc file caused issues parallel installing for different versions of python * putting it into the module allows us to give the correct directory based on which version of python you run the script from * access the var as such: import gi installdir = gi._overridesdir
* structs are sometimes a pain in gi. Simply constructing them using the the standard constructor (e.g. Gtk.TargetEntry()) will malloc the struct but not correctly initialize the fields which can cause a crash. * tests didn't crash before because they were sending in bogus data that somehow did not trigger the issue * now with the C struct array marshallers doing the right thing, the incorrect use of TargetEntry was causing a crash https://bugzilla.gnome.org/show_bug.cgi?id=627236
…arshalling * there is no way in GI to tell if a C array is flat or an array of pointers so we assume that all arrays of simple structs and gvalues are flat and all arrays of objects and boxed structs are pointer arrays. * this will be removed once GI gets the ability to annotate level of indirection for arrays https://bugzilla.gnome.org/show_bug.cgi?id=627236
* if the child arg comes before the parent arg we need to update the argument counts and take the child arg out of the marshalling lists since it is handled by the parent * when two parents reference the same child arg as is the case with two arrays which have a single length argument we only want to update the count once * to do this we introduce the PYGI_META_ARG_CHILD_NEEDS_UPDATE meta type and only do the count update if this is set * APIs should keep in mind that this take extra processing so child args should really come after their parents https://bugzilla.gnome.org/show_bug.cgi?id=627236
…tage * This only applys to python subclasses of GObject which are instantiated using GObject.new * Because we were creating the wrapper when the gobject is initialized and then again calling pygobject_new_full the wrapper would get ref'ed twice. * we could not simply Py_DECREF the wrapper due to the fact that non-subclassed objects (e.g. GObject.Object) instantiated via new do not run the same initialization code and would not have the extra ref * solution was to simply not create the wrapper during initialization because if it doesn't exist when pygobject_new_full is called it gets created and registered there * move the call to __init__ into pyg_object_new https://bugzilla.gnome.org/show_bug.cgi?id=657403
This method was used in gobject initialization at some point, but now using GObject.__init__() is sufficient, so let's not keep this old method around and let people misuse it. https://bugzilla.gnome.org/show_bug.cgi?id=658032
* we are lucky this bit of code worked for as long as it did but when checking if an object is a PyGFlag we can't just rely on looking at the g_type field because if a regular gobject is passed in as is the case when you compare a long to a gflag, the gobject will not have a g_type field. Accessing a non-existant field could at best give you a false positive and at worse read memory beyond the bounds of the actual structure passed in
…is for us
* in/out make sense from a C perspective but when you get to the python layers it makes more sense to label them as to_py and from_py to denote which way we are marshalling * this helps clear up the difference between callbacks which call into python and invoked functions which call into C * in the callback case we marshal in values to Python objects and out values to C types but in the invoke case we do the reverse. Dealing with to_py/from_py makes the code much more resuable and consistant https://bugzilla.gnome.org/show_bug.cgi?id=658362