| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
new_from_data isn't bindable (see https://bugzilla.gnome.org/show_bug.cgi?id=721497)
and will result in use after free. While we could try to move people away from it and
skip it in GI a github code search turns up quite a few users.
This adds an override for it, wrapping GdkPixbuf.Pixbuf.new_from_bytes, and marks any
usage of the callback args as deprecated.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using a GPtrArray as the value type of a GHashTable currently produces a
warning:
Unsupported type array
for example when calling a function whose return type is annotated as:
(transfer container) (element-type filename GPtrArray<SomeObject>)
Since we don’t treat objects (GI_TYPE_TAG_INTERFACE) specially when
marshalling to/from GHashTable, we shouldn’t need to treat arrays
specially either. Handle the case explicitly.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
|
|
|
|
|
|
| |
pacman doesn't support installing packages without doing a system upgrade
first. In case the user already has msys2 installed but not used in a while
just doing the install might not work.
|
| |
|
| |
|
|
|
|
| |
we run the whole test suite as one test
|
|
|
|
| |
pypy+pycairo doesn't work because it doesn't install a .pc file with it.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
through SIGINT. Fixes #219
We didn't remove them if the event loops returned normally.
This also fixes a small race where a SIGINT gets ignored right after the yield check and before
the old handler is reinstated. Check after the signal handler is switched back instead.
This resulted in GLib.MainLoop and Gio.Aplication instances leaking.
|
| |
|
|
|
|
|
|
| |
disable it
If you don't want pycairo support pass "-Dpycairo=false"
|
| |
|
|\
| |
| |
| |
| | |
docs: Add introduction to handling GLib.Error
See merge request GNOME/pygobject!69
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
After chaining up accessing anything on the instance will crash like
accessing self.g_type in this case. Guard against that by exposing if the
wrapped boxed is still there.
Ideally we shouldn't invalidate the object in __del__, but various
things depend on it atm. For another time..
|
| |
| |
| |
| |
| | |
Debian seems to have started using LTO for Python and some symbol names
have a ".lto_priv" suffix now.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a GValueArray is created from a list of GValues, it should not wrap
these GValues in a second layer of GValues before appending to the
array. The end result should be a GValueArray of GValues, not a
GValueArray of GValues holding another GValue (unless the user
explicitly creates such a value).
With this patch the behavior is now consistent when creating a
GValueArray and appending GValues directly, and creating a GValueArray
within a GValue based on a list of GValues.
For instance, to create a GValueArray of G_TYPE_UINT the user must
create GValues manually and create a GValueArray from these. The result
should be a GValueArray of GValues that hold G_TYPE_UINT, not a
GValueArray that contain GValues that hold a GValue that holds
G_TYPE_UINT.
See !66
|
|
|
|
|
|
|
|
|
| |
find_module() should either return None or a loader, but we raised ImportError
there in case we already knew that the namespace was missing.
Move that check to load_module() instead. While there shouldn't be any functional
difference, raising in find_module() under Python 3 resulted in a chained
exception with an unrelated error message printed first.
|
|
|
|
|
|
|
|
|
|
| |
Adds ActionMap and ActionMap.add_action_entries() to allow for adding
multiple actions as a list of tuples in which each element defines
a single action like the GActionEntry C struct.
https://bugzilla.gnome.org/show_bug.cgi?id=678655
Original Author: Micah Carrick <micah@quixotix.com>
|
|
|
|
|
| |
We have to assign PyCFunctionWithKeywords functions to PyCFunction fields
everywhere, so not much we can do. Ideas welcome.
|
|
|
|
|
| |
We check the exact version number but that has changed with the last update.
Check the major/minor + impl instead.
|
|
|
|
| |
This is now fixed in PyPy and pip
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
as suggested by Patrick in !62
|
|
|
|
| |
as suggested by Patrick in !62
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Release the GIL when emitting signals to avoid potential deadlocks
if the signal handling needs to call back into python from another
C thread.
|
| |
|
|
|
|
| |
See !66
|
|
|
|
|
| |
gitlab likes to ban users who trigger too many jobs, so let's
reduce the default amount a bit.
|
|
|
|
| |
We require Ubuntu 16.04+ which has 3.5
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The gvalue code had special code for handling G_TYPE_CHAR/UCHAR
allowing as input roughly what u/int8 allows plus unicode.
Since GI maps g(u)char to u/int8 it's a good idea that both support
the same input ranges for numbers/bytes so that there is no difference
between gtype/GI.
pygi_gschar_from_py is a superset of gint8 + unicode.
pygi_guchar_from_py is a superset of guint8 + unicode.
|
|
|
|
| |
reduces the output at build time a bit
|
| |
|
|
|
|
| |
it helps
|
|
|
|
|
|
| |
does't support that.
TypeError is wrong there anyway.
|