| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
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
|