summaryrefslogtreecommitdiff
path: root/gi/pygi-property.h
Commit message (Collapse)AuthorAgeFilesLines
* Fast path Python Property getter when accessed through GObject interfacesSimon Feltman2014-08-181-0/+3
| | | | | | | | | Break do_get_property() call into a re-usable function. Call do_get_property() Python implementations instead of going through GObject machinery for Python GObjects. This gives a performance boost for Python GObject properties when accessed via. obj.get_property() and obj.props. https://bugzilla.gnome.org/show_bug.cgi?id=723872
* Unify property gettersSimon Feltman2014-08-171-0/+4
| | | | | | | | | | | Consolidate duplicate logic into pygi_get_property_value(). Use the function for GObject.get_property(), GObject.get_properties(), and GObject.props. Remove overridden expected failures in TestCGetPropertyMethod which now work due to the unification. https://bugzilla.gnome.org/show_bug.cgi?id=733893 https://bugzilla.gnome.org/show_bug.cgi?id=726999
* Move pygi foreign API into pygi-foreign-api.hSimon Feltman2014-05-051-6/+8
| | | | | | | | | | | Move limited set of APIs necessary for registering foreign marshalers into pygi-foreign-api.h. Remove "_real" from internally used APIs and add necessary includes to the rest of pygobject for calling directly (instead of going through the PyCapsule API within PyGI itself). This is needed to avoid compilation errors when including pygobject.h in foreign marshaling plugins which conflicts with pygobject-private.h. https://bugzilla.gnome.org/show_bug.cgi?id=694604
* Fix property lookup in class hierarchyDaniel Drake2012-11-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 4bfe7972546413f46f5c36737ff03bb5612c1921 introduced a bug where a Python subclass of a gi-provided base class overrides a property from the base class. The new behaviour in the above commit causes pygobject to seek the property in the base class and try to read it from there (resulting in confusion) rather than noticing that the property is overridden and present in the Python object instance. To provide a nicer solution here, we can exploit the fact that g_object_class_find_property() will traverse the hierarchy in order to find the right GParamSpec, and the returned GParamSpec can tell us exactly which GType introduces the property. The strategy is: 1. Find pspec with g_object_class_find_property() 2. Find the class that owns that property (pspec->owner_type) 3. See if girepository owns that class. 3a. If yes, get property from there. 3b. If not, get property "directly" And the same for property setting. Now that _pygi_lookup_property_from_g_type is always passed the type that implements the property, it no longer has to go recursing through parent classes, which was the original cause of confusion. https://bugzilla.gnome.org/show_bug.cgi?id=686942
* Implement getting and setting properties using introspection information.Tomeu Vizoso2010-07-271-0/+39
This allows us to use information not present in GObject such as transfer and element types. https://bugzilla.gnome.org/show_bug.cgi?id=620808