pygobject issueshttps://gitlab.gnome.org/GNOME/pygobject/-/issues2018-05-24T20:09:23Zhttps://gitlab.gnome.org/GNOME/pygobject/-/issues/154GLib.VariantType.next broken on PyGObject2018-05-24T20:09:23ZAlberto RuizGLib.VariantType.next broken on PyGObjectWhile working on #152 I noticed that GLib.VariantType.next has a really odd behaviour on Python.
This is the expected behaviour from this C snippet:
```
#include <glib/gi18n.h>
int
main (int argc,
char *argv[])
{
const GVaria...While working on #152 I noticed that GLib.VariantType.next has a really odd behaviour on Python.
This is the expected behaviour from this C snippet:
```
#include <glib/gi18n.h>
int
main (int argc,
char *argv[])
{
const GVariantType *gv = G_VARIANT_TYPE ("(siv)");
const GVariantType *next = g_variant_type_first (gv);
g_printf ("%s\n", g_variant_type_dup_string (next));
next = g_variant_type_next(next);
g_printf ("%s\n", g_variant_type_dup_string (next));
next = g_variant_type_next(next);
g_printf ("%s\n", g_variant_type_dup_string (next));
return 0;
}
```
That would output three lines with 's', 'i' and 'v'.
However, this Python snippet:
```
In [2]: from gi.repository import GLib
In [3]: t = GLib.VariantType("(siv)")
In [4]: f = t.first()
In [5]: f.dup_string()
Out[5]: 's'
In [6]: s = f.next()
In [7]: s.dup_string()
Out[7]: ''
```
next always returns a new type with an empty string, something odd is happening at the wrapper level (note that first and next just create a pointer to the next position of the format string as GVariantType is an empty struct).https://gitlab.gnome.org/GNOME/pygobject/-/issues/148Cannot use functions which take GObject.EnumClass as arguments2024-01-02T01:34:35ZChristoph ReiterCannot use functions which take GObject.EnumClass as argumentsOriginal issue: https://bugzilla.gnome.org/show_bug.cgi?id=776378
Cannot use functions which take GObject.EnumClass as arguments
Particularly GObject.enum_get_value_by_nick() is not functioning. Normally GType or GI classes are automat...Original issue: https://bugzilla.gnome.org/show_bug.cgi?id=776378
Cannot use functions which take GObject.EnumClass as arguments
Particularly GObject.enum_get_value_by_nick() is not functioning. Normally GType or GI classes are automatically coerced to GObjectClass instances. In the case of GObject.GEnum, it is directly derived from the builtin Python "int" so this may be problematic.
Example:
```python
from gi.repository import GObject, Gio
GObject.enum_get_value_by_nick(Gio.BusType, 'system')
Traceback (most recent call last):
File "enum.py", line 3, in <module>
GObject.enum_get_value_by_nick(Gio.BusType, 'system')
TypeError: argument enum_class: Expected GObject.EnumClass, but got gi.repository.Gio.type
```https://gitlab.gnome.org/GNOME/pygobject/-/issues/146Add support for Python 3 asyncio event loop (PEP 3156)2022-01-08T17:56:38ZBugzillaAdd support for Python 3 asyncio event loop (PEP 3156)## Submitted by Patrick Griffis `@pgriffis`
**[Link to original bug (#791591)](https://bugzilla.gnome.org/show_bug.cgi?id=791591)**
## Description
Python 3 now has built in async features[1] which are a perfect fit for Gio's async A...## Submitted by Patrick Griffis `@pgriffis`
**[Link to original bug (#791591)](https://bugzilla.gnome.org/show_bug.cgi?id=791591)**
## Description
Python 3 now has built in async features[1] which are a perfect fit for Gio's async APIs.
An implementation using GLib already exists in gbulb[2] though one problem brought up is that it is Apache-2.0 licensed.
[1] - https://docs.python.org/3/library/asyncio.html
[2] - https://github.com/nathan-hoad/gbulbhttps://gitlab.gnome.org/GNOME/pygobject/-/issues/140Confusing error on Gtk.Application.add_option_group2023-08-02T21:40:41ZBugzillaConfusing error on Gtk.Application.add_option_group## Submitted by yangfl
**[Link to original bug (#786735)](https://bugzilla.gnome.org/show_bug.cgi?id=786735)**
## Description
When I try to add some OptionGroup to Gtk.Application, I get error.## Submitted by yangfl
**[Link to original bug (#786735)](https://bugzilla.gnome.org/show_bug.cgi?id=786735)**
## Description
When I try to add some OptionGroup to Gtk.Application, I get error.https://gitlab.gnome.org/GNOME/pygobject/-/issues/136Problematic use of Gtk.Builder in examples and demos2018-01-12T06:57:50ZBugzillaProblematic use of Gtk.Builder in examples and demos## Submitted by lovetox
**[Link to original bug (#784728)](https://bugzilla.gnome.org/show_bug.cgi?id=784728)**
## Description
The Gtk.Builder demo/example in the repo
https://gitlab.gnome.org/GNOME/pygobject/blob/master/examples/d...## Submitted by lovetox
**[Link to original bug (#784728)](https://bugzilla.gnome.org/show_bug.cgi?id=784728)**
## Description
The Gtk.Builder demo/example in the repo
https://gitlab.gnome.org/GNOME/pygobject/blob/master/examples/demo/demos/builder.py
in this example a reference is set to the Gtk.Builder object on self, then with connect_signals(self), Gtk.Builder gets a reference of BuilderApp.
I dont know what Gtk.Builder exactly does with that reference but from my tests it creates a ref cylce that it seems python can not detect.
Hence neither Gtk.Builder nor BuilderApp is garbage collected ever.
Just dont quit Gtk on destroy, and create a list with some million entrys on the class.
if you run this and close the window, the class is never garbage collected because Gtk.Builder holds somewhere a reference to it. The memory is not released.
If you run the same example but comment out
"self.builder.connect_signals(self)"
the class is garbage collected.
Im aware that this could be considered not a bug.
But then we should at least hint somewhere in the documentation or in the examples that this ref cycle has to be broken somehow.
Im curious how other devs handle this, or if they are aware of it.
Here my test:
```python
import os
from gi.repository import Gtk
class BuilderApp:
def __init__(self, demoapp):
self.demoapp = demoapp
self.builder = Gtk.Builder()
if demoapp is None:
filename = os.path.join('data', 'demo.ui')
else:
filename = demoapp.find_file('demo.ui')
self.builder.add_from_file(filename)
self.builder.connect_signals(self)
window = self.builder.get_object('window1')
window.connect('destroy', self.quit_activate)
window.show_all()
self.list_ = []
for x in range(10000000):
self.list_.append('test')
def about_activate(self, action):
about_dlg = self.builder.get_object('aboutdialog1')
about_dlg.run()
about_dlg.hide()
def quit_activate(self, action):
return
def main(demoapp=None):
BuilderApp(demoapp)
Gtk.main()
if __name__ == '__main__':
main()
```https://gitlab.gnome.org/GNOME/pygobject/-/issues/132Add Examples for Gio.Socket and related network methods2018-01-12T06:53:36ZBugzillaAdd Examples for Gio.Socket and related network methods## Submitted by lovetox
**[Link to original bug (#782177)](https://bugzilla.gnome.org/show_bug.cgi?id=782177)**
## Description
Also
Gio.SocketClient
Gio.TlsClientConnection
How can we use these Objects with GLib.io_add_watch()
Gr...## Submitted by lovetox
**[Link to original bug (#782177)](https://bugzilla.gnome.org/show_bug.cgi?id=782177)**
## Description
Also
Gio.SocketClient
Gio.TlsClientConnection
How can we use these Objects with GLib.io_add_watch()
Great would be an example that goes beyond sending one single message to an address. Something like a Server and Client exchanging multiple messages.
Would the same Code work on Windows too? and so on..
Great that all these things exist, but its very hard to get into it if there is not one working example on the net.https://gitlab.gnome.org/GNOME/pygobject/-/issues/125Improve GTask wrapping2022-03-18T02:13:42ZBugzillaImprove GTask wrapping## Submitted by Garrett Regier `@gregier`
**[Link to original bug (#773254)](https://bugzilla.gnome.org/show_bug.cgi?id=773254)**
## Description
The run_in_thread() and run_in_thread_sync() methods are a bit weird and PyGObject cann...## Submitted by Garrett Regier `@gregier`
**[Link to original bug (#773254)](https://bugzilla.gnome.org/show_bug.cgi?id=773254)**
## Description
The run_in_thread() and run_in_thread_sync() methods are a bit weird and PyGObject cannot use set_task_data().
### Depends on
* [Bug 693576](https://bugzilla.gnome.org/show_bug.cgi?id=693576)
* [Bug 773250](https://bugzilla.gnome.org/show_bug.cgi?id=773250)https://gitlab.gnome.org/GNOME/pygobject/-/issues/122SIGSEGV occasionally upon invoke of c callable2022-12-29T00:57:13ZBugzillaSIGSEGV occasionally upon invoke of c callable## Submitted by Christian Hergert `@chergert`
**[Link to original bug (#771956)](https://bugzilla.gnome.org/show_bug.cgi?id=771956)**
## Description
I'm not familiar with the codebase, so not sure how much I can help tracking this d...## Submitted by Christian Hergert `@chergert`
**[Link to original bug (#771956)](https://bugzilla.gnome.org/show_bug.cgi?id=771956)**
## Description
I'm not familiar with the codebase, so not sure how much I can help tracking this down more than providing a stacktrace.
Thread 1 "lt-gnome-builde" received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
```
(gdb) bt
#0 0x0000000000000000 in ?? ()
#1 0x00007fffd2b547ef in _invoke_marshal_out_args (state=0x7fffffffc0d0, function_cache=0x2078000) at /home/christian/Projects/pygobject/gi/pygi-invoke.c:565
#2 0x00007fffd2b54c3c in pygi_invoke_c_callable (function_cache=0x2078000, state=0x7fffffffc0d0, py_args=0x7fffc80afd08, py_kwargs=0x0) at /home/christian/Projects/pygobject/gi/pygi-invoke.c:706
#3 0x00007fffd2b5625b in _function_cache_invoke_real (function_cache=0x2078000, state=0x7fffffffc0d0, py_args=0x7fffc80afd08, py_kwargs=0x0) at /home/christian/Projects/pygobject/gi/pygi-cache.c:783
#4 0x00007fffd2b56462 in pygi_function_cache_invoke (function_cache=0x2078000, py_args=0x7fffc80afd08, py_kwargs=0x0) at /home/christian/Projects/pygobject/gi/pygi-cache.c:862
#5 0x00007fffd2b54cbf in pygi_callable_info_invoke (info=0xb075e0, py_args=0x7fffc80afd08, kwargs=0x0, cache=0x2078000, user_data=0x0) at /home/christian/Projects/pygobject/gi/pygi-invoke.c:722
#6 0x00007fffd2b54e04 in _wrap_g_callable_info_invoke (self=0x7fffd20887d8, py_args=0x7fffc80afd08, kwargs=0x0) at /home/christian/Projects/pygobject/gi/pygi-invoke.c:759
#7 0x00007fffd2b40bcb in _callable_info_call (self=0x7fffb4bb6650, args=0x7fffc805fda0, kwargs=0x0) at /home/christian/Projects/pygobject/gi/pygi-info.c:561
#8 0x00007fffd2b40e74 in _function_info_call (self=0x7fffb4bb6650, args=0x7fffc805fda0, kwargs=0x0) at /home/christian/Projects/pygobject/gi/pygi-info.c:627
#9 0x00007ffff650fed7 in PyObject_Call () from /lib64/libpython3.5m.so.1.0
#10 0x00007ffff65cb4b1 in PyEval_EvalFrameEx () from /lib64/libpython3.5m.so.1.0
#11 0x00007ffff65d05e3 in _PyEval_EvalCodeWithName () from /lib64/libpython3.5m.so.1.0
#12 0x00007ffff65cce59 in PyEval_EvalFrameEx () from /lib64/libpython3.5m.so.1.0
#13 0x00007ffff65ced1b in PyEval_EvalFrameEx () from /lib64/libpython3.5m.so.1.0
#14 0x00007ffff65d05e3 in _PyEval_EvalCodeWithName () from /lib64/libpython3.5m.so.1.0
#15 0x00007ffff65d06c3 in PyEval_EvalCodeEx () from /lib64/libpython3.5m.so.1.0
#16 0x00007ffff653abf8 in function_call () from /lib64/libpython3.5m.so.1.0
#17 0x00007ffff650fed7 in PyObject_Call () from /lib64/libpython3.5m.so.1.0
#18 0x00007ffff6526934 in method_call () from /lib64/libpython3.5m.so.1.0
#19 0x00007ffff650fed7 in PyObject_Call () from /lib64/libpython3.5m.so.1.0
#20 0x00007ffff65c6d37 in PyEval_CallObjectWithKeywords () from /lib64/libpython3.5m.so.1.0
#21 0x00007fffd2b53252 in pygi_signal_closure_marshal (closure=0x3002db0, return_value=0x0, n_param_values=2, param_values=0x7fffffffcd50, invocation_hint=0x7fffffffcc90, marshal_data=0x0)
at /home/christian/Projects/pygobject/gi/pygi-signal-closure.c:196
#22 0x00007fffef1018aa in g_closure_invoke (closure=0x3002db0, return_value=0x0, n_param_values=2, param_values=0x7fffffffcd50, invocation_hint=0x7fffffffcc90)
at /home/christian/Projects/glib/gobject/gclosure.c:804
#23 0x00007fffef11dd16 in signal_emit_unlocked_R (node=0x210cb80, detail=0, instance=0x12b4b70, emission_return=0x0, instance_and_params=0x7fffffffcd50) at /home/christian/Projects/glib/gobject/gsignal.c:3635
#24 0x00007fffef11d04d in g_signal_emit_valist (instance=0x12b4b70, signal_id=461, detail=0, var_args=0x7fffffffd018) at /home/christian/Projects/glib/gobject/gsignal.c:3391
#25 0x00007fffef11d58f in g_signal_emit (instance=0x12b4b70, signal_id=461, detail=0) at /home/christian/Projects/glib/gobject/gsignal.c:3447
#26 0x00007ffff75af972 in ide_buffer_manager_save_file__save_cb (object=0x1667100, result=0x1964000, user_data=0x1c723a0) at buffers/ide-buffer-manager.c:926
#27 0x00007ffff054194b in g_task_return_now (task=0x1964000) at /home/christian/Projects/glib/gio/gtask.c:1121
#28 0x00007ffff0541a53 in g_task_return (task=0x1964000, type=G_TASK_RETURN_SUCCESS) at /home/christian/Projects/glib/gio/gtask.c:1179
#29 0x00007ffff054258a in g_task_return_boolean (task=0x1964000, result=1) at /home/christian/Projects/glib/gio/gtask.c:1680
#30 0x00007ffff72cc91d in query_info_cb (source_object=0x83acc0, result=0x1964410, user_data=0x1964000) at /home/christian/Projects/gtksourceview/gtksourceview/gtksourcefilesaver.c:578
#31 0x00007ffff054194b in g_task_return_now (task=0x1964410) at /home/christian/Projects/glib/gio/gtask.c:1121
#32 0x00007ffff0541994 in complete_in_idle_cb (task=0x1964410) at /home/christian/Projects/glib/gio/gtask.c:1135
#33 0x00007fffeee1ccfe in g_idle_dispatch (source=0x7fffa8011570, callback=0x7ffff054197c <complete_in_idle_cb>, user_data=0x1964410) at /home/christian/Projects/glib/glib/gmain.c:5545
#34 0x00007fffeee1a27c in g_main_dispatch (context=0x64c790) at /home/christian/Projects/glib/glib/gmain.c:3203
#35 0x00007fffeee1b12d in g_main_context_dispatch (context=0x64c790) at /home/christian/Projects/glib/glib/gmain.c:3856
#36 0x00007fffeee1b312 in g_main_context_iterate (context=0x64c790, block=1, dispatch=1, self=0x640ec0) at /home/christian/Projects/glib/glib/gmain.c:3929
#37 0x00007fffeee1b3d6 in g_main_context_iteration (context=0x64c790, may_block=1) at /home/christian/Projects/glib/glib/gmain.c:3990
#38 0x00007ffff055dcd0 in g_application_run (application=0x6490f0, argc=2, argv=0x7fffffffd5f8) at /home/christian/Projects/glib/gio/gapplication.c:2381
#39 0x0000000000401255 in main (argc=2, argv=0x7fffffffd5f8) at main.c:68
```https://gitlab.gnome.org/GNOME/pygobject/-/issues/121It is not possible to instantiate a TreePath empty2022-12-30T22:12:53ZBugzillaIt is not possible to instantiate a TreePath empty## Submitted by Cédric Krier
**[Link to original bug (#770665)](https://bugzilla.gnome.org/show_bug.cgi?id=770665)**
## Description
Created attachment 334547
patch
The `__new__` method of TreePath has zero as default value for path...## Submitted by Cédric Krier
**[Link to original bug (#770665)](https://bugzilla.gnome.org/show_bug.cgi?id=770665)**
## Description
Created attachment 334547
patch
The `__new__` method of TreePath has zero as default value for path. So this makes it point to the first row. But indeed it could be needed to instantiate a TreePath empty. For example, it is needed to call rows_reordered which must reorder the all tree.
Here is a patch that allow to use None, () and '' as path.
Also I put None as default value for path because it seems more logical but if it is needed for backward compatibility, we can keep 0 as default value.
FYI, it is possible to get a empty TreePath with this code:
path = Gtk.TreePath()
path.up()
~~**Patch 334547**~~, "patch":
[TreePath.patch](/uploads/24d27324672f98cb4686f658466ae274/TreePath.patch)https://gitlab.gnome.org/GNOME/pygobject/-/issues/120Styles have empty lists for style properties2023-08-03T04:59:48ZBugzillaStyles have empty lists for style properties## Submitted by ShadowKyogre
**[Link to original bug (#770573)](https://bugzilla.gnome.org/show_bug.cgi?id=770573)**
## Description
Created attachment 334399
Minimal demonstration code for the bug, PyGI
## Metadata
Version tested ...## Submitted by ShadowKyogre
**[Link to original bug (#770573)](https://bugzilla.gnome.org/show_bug.cgi?id=770573)**
## Description
Created attachment 334399
Minimal demonstration code for the bug, PyGI
## Metadata
Version tested with: 2.28.6
Compared with for expected behavior: pygtk 2.24.0
## Steps to reproduce
1. Get the style for a widget via calling its get_style method
2. Access a style property (such as bg)
## Expected Results
A list of colors containing the style
## Actual Results
An empty list, making it impossible to pick up colors if they aren't assigned to a theme variable.
## Why is this important?
Some old themes like Murrina Gilouche do not set GTK2 theme variables that would normally be used to detect certain states. Furthermore, GTK themes can tweak things on a per-widget basis, so this would allow a more foolproof picking up of colors in these edge cases.
**Attachment 334399**, "Minimal demonstration code for the bug, PyGI":
[gtk2-pygi.py](/uploads/d7ce74c948a4f4c98f721a28ce1bf39a/gtk2-pygi.py)https://gitlab.gnome.org/GNOME/pygobject/-/issues/118Provide alternative enum attribute in case it starts with a digit2018-01-10T20:54:44ZBugzillaProvide alternative enum attribute in case it starts with a digit## Submitted by Christoph Reiter `@creiter`
**[Link to original bug (#768471)](https://bugzilla.gnome.org/show_bug.cgi?id=768471)**
## Description
https://mail.gnome.org/archives/gir-devel-list/2016-July/msg00000.html
Example:
The...## Submitted by Christoph Reiter `@creiter`
**[Link to original bug (#768471)](https://bugzilla.gnome.org/show_bug.cgi?id=768471)**
## Description
https://mail.gnome.org/archives/gir-devel-list/2016-July/msg00000.html
Example:
There exists a GLib.SpawnError.2BIG which should be accessible under GLib.SpawnError._2BIG
https://docs.python.org/3/reference/lexical_analysis.html#identifiershttps://gitlab.gnome.org/GNOME/pygobject/-/issues/114Python bytearray to GBytes conversion is very slow2023-08-03T05:20:25ZBugzillaPython bytearray to GBytes conversion is very slow## Submitted by Bug flys
**[Link to original bug (#766716)](https://bugzilla.gnome.org/show_bug.cgi?id=766716)**
## Description
The conversion from bytearray to GBytes is very slow. On the other hand, the conversion from bytes to GB...## Submitted by Bug flys
**[Link to original bug (#766716)](https://bugzilla.gnome.org/show_bug.cgi?id=766716)**
## Description
The conversion from bytearray to GBytes is very slow. On the other hand, the conversion from bytes to GBytes is fast.
bytes -> GBytes is over 100x faster than bytearray -> GBytes.
test code:
from gi.repository import GLib
import time
data_b = b" "* 2**24
t0 = time.time()
data_ba = bytearray(data_b)
t1 = time.time()
gbyte = GLib.Bytes(data_b)
t2 = time.time()
gbyte2 = GLib.Bytes(data_ba)
t3 = time.time()
data_bback = bytes(data_ba)
t4 = time.time()
print("Data size:", len(data_b))
print("bytes -> bytearray:", t1 - t0)
print("bytes -> GBytes: ", t2 - t1)
print("bytearray -> GBytes: ", t3 - t2)
print("bytearray -> bytes: ", t4 - t3)https://gitlab.gnome.org/GNOME/pygobject/-/issues/109Union type not working correctly with python 3 and GObject introspection2023-08-06T09:44:19ZBugzillaUnion type not working correctly with python 3 and GObject introspection## Submitted by Vratislav Podzimek
**[Link to original bug (#761101)](https://bugzilla.gnome.org/show_bug.cgi?id=761101)**
## Description
Created attachment 319698
the reproducer sources
Description of problem:
If I have a union ty...## Submitted by Vratislav Podzimek
**[Link to original bug (#761101)](https://bugzilla.gnome.org/show_bug.cgi?id=761101)**
## Description
Created attachment 319698
the reproducer sources
Description of problem:
If I have a union type in my GObject-based code and try to use it from python 3, the right value doesn't get to the "C side". However, this works just fine with python 2. Running the attached reproducer I get this:
$ GI_TYPELIB_PATH=. LD_LIBRARY_PATH=. python reproducer.py
got unit with int value: 1
got unit with int value: 2
got unit with int value: 3
$ GI_TYPELIB_PATH=. LD_LIBRARY_PATH=. python3 reproducer.py
got unit with int value: 1
got unit with int value: 1
got unit with int value: 1
How reproducible:
100%
Steps to Reproduce:
1. unpack the attached reproducer
2. run rebuild_test_data.sh
3. run $ GI_TYPELIB_PATH=. LD_LIBRARY_PATH=. python reproducer.py
4. run $ GI_TYPELIB_PATH=. LD_LIBRARY_PATH=. python3 reproducer.py
Actual results:
different behaviour for python 2 (correct) and python 3 (wrong)
Expected results:
the same (correct) behaviour in python 3 as in python 2
Additional info:
this blocks python-blivet [1] from starting to use the new libbytesize library [2]
[1] https://github.com/rhinstaller/blivet
[2] https://github.com/rhinstaller/libbytesize
**Attachment 319698**, "the reproducer sources":
[reproducer.tar.gz](/uploads/4e7b1649f3735a4cca9e6252288ea55e/reproducer.tar.gz)https://gitlab.gnome.org/GNOME/pygobject/-/issues/106GObject.disconnect_by_func only disconnect one instance of the signal connection2022-09-17T20:31:10ZBugzillaGObject.disconnect_by_func only disconnect one instance of the signal connection## Submitted by Thibault Saunier
**[Link to original bug (#759249)](https://bugzilla.gnome.org/show_bug.cgi?id=759249)**
## Description
Created attachment 317038
Test case showing the issue.
The g_signal_handlers_disconnect_by_func...## Submitted by Thibault Saunier
**[Link to original bug (#759249)](https://bugzilla.gnome.org/show_bug.cgi?id=759249)**
## Description
Created attachment 317038
Test case showing the issue.
The g_signal_handlers_disconnect_by_func states:
Disconnects all handlers on an instance that match func and data .
But the attached code sample shows that it only disconnects one handler in pygobject.
**Attachment 317038**, "Test case showing the issue.":
[test_signal_disconnect.py](/uploads/8967a50c5941ff0ccf81a92a3fe63b06/test_signal_disconnect.py)https://gitlab.gnome.org/GNOME/pygobject/-/issues/105Method do_get_info() on class Gio.DBusInterfaceSkeleton is ambiguous with met...2020-05-19T16:18:38ZBugzillaMethod do_get_info() on class Gio.DBusInterfaceSkeleton is ambiguous with methods in base classes Gio.DBusInterfaceSkeleton and Gio.DBusInterface## Submitted by Guy M Streeter
**[Link to original bug (#759142)](https://bugzilla.gnome.org/show_bug.cgi?id=759142)**
## Description
DBusInterfaceSkeleton inherits from DBusInterface and they both have a do_get_info()## Submitted by Guy M Streeter
**[Link to original bug (#759142)](https://bugzilla.gnome.org/show_bug.cgi?id=759142)**
## Description
DBusInterfaceSkeleton inherits from DBusInterface and they both have a do_get_info()https://gitlab.gnome.org/GNOME/pygobject/-/issues/98Implement g_settings_bind_with_mapping and handle range/flag __setitem__2023-11-26T18:32:11ZBugzillaImplement g_settings_bind_with_mapping and handle range/flag __setitem__## Submitted by dal..@..com.hk
**[Link to original bug (#746724)](https://bugzilla.gnome.org/show_bug.cgi?id=746724)**
## Description
Created attachment 300247
fix patch
g_settings_bind is a function that binds an object property w...## Submitted by dal..@..com.hk
**[Link to original bug (#746724)](https://bugzilla.gnome.org/show_bug.cgi?id=746724)**
## Description
Created attachment 300247
fix patch
g_settings_bind is a function that binds an object property with a settings key. This is available in the python binding.
g_settings_bind_with_mapping allows users to assign a mapping that converts the settings value to the desired widget value and vice versa, eg. when the widget value should be twice the settings value. This is not available in the python binding (possibly due to the difficulty in introspecting functions). This patch implements this function in the gi overrides.
Implementing this requires properly implementing the __setitem__ override. The __setitem__ override allows users to access schema values through
settings = Gio.Settings.new(schema)
value = settings[key]
However, this is only implemented for key types "type" and "enum". Attempting to use it for the other types "range" and "flags" will raise a NotImplementedError. So this patch implements this functionality for all possible key types.
For reference, support for "enum" was implemented here: https://bugzilla.gnome.org/show_bug.cgi?id=685947
~~**Patch 300247**~~, "fix patch":
[0001-Implement-g_settings_bind_with_mapping-and-handle-ra.patch](/uploads/bdd6ef6ee51a50f82d75673e43c1395b/0001-Implement-g_settings_bind_with_mapping-and-handle-ra.patch)Dan YeawDan Yeawhttps://gitlab.gnome.org/GNOME/pygobject/-/issues/88Leak when marshaling GValue return/output args with transfer-full2023-08-05T17:19:01ZBugzillaLeak when marshaling GValue return/output args with transfer-full## Submitted by Simon Feltman
**[Link to original bug (#736514)](https://bugzilla.gnome.org/show_bug.cgi?id=736514)**
## Description
```
$ make check.valgrind TEST_NAMES=test_everything.TestEverything.test_strv_in_gvalue
==7604== 7...## Submitted by Simon Feltman
**[Link to original bug (#736514)](https://bugzilla.gnome.org/show_bug.cgi?id=736514)**
## Description
```
$ make check.valgrind TEST_NAMES=test_everything.TestEverything.test_strv_in_gvalue
==7604== 70 (24 direct, 46 indirect) bytes in 1 blocks are definitely lost in loss record 3,973 of 8,963
==7604== at 0x4C291D4: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7604== by 0x14D7BE5D: g_malloc0 (gmem.c:127)
==7604== by 0x14D7C171: g_malloc0_n (gmem.c:356)
==7604== by 0x1A9A59FF: regress_test_strv_in_gvalue (regress.c:3933)
==7604== by 0xE8F1D8B: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.1)
==7604== by 0xE8F16BB: ffi_call (in /usr/lib64/libffi.so.6.0.1)
==7604== by 0x13E9E5B3: pygi_invoke_c_callable (pygi-invoke.c:628)
==7604== by 0x13E9F893: _function_cache_invoke_real (pygi-cache.c:714)
==7604== by 0x13E9FA92: pygi_function_cache_invoke (pygi-cache.c:793)
==7604== by 0x13E9E6B5: pygi_callable_info_invoke (pygi-invoke.c:671)
==7604== by 0x13E9E7F9: _wrap_g_callable_info_invoke (pygi-invoke.c:708)
==7604== by 0x13E8B79A: _callable_info_call (pygi-info.c:568)
==7604== by 0x13E8B998: _function_info_call (pygi-info.c:623)
==7604== by 0x4E9047B: PyObject_Call (in /usr/lib64/libpython3.3m.so.1.0)
==7604== by 0x4F3D0F6: PyEval_EvalFrameEx (in /usr/lib64/libpython3.3m.so.1.0)
==7604== by 0x4F40869: PyEval_EvalFrameEx (in /usr/lib64/libpython3.3m.so.1.0)
==7604== by 0x4F42174: PyEval_EvalCodeEx (in /usr/lib64/libpython3.3m.so.1.0)
==7604== by 0x4F40573: PyEval_EvalFrameEx (in /usr/lib64/libpython3.3m.so.1.0)
==7604== by 0x4F42174: PyEval_EvalCodeEx (in /usr/lib64/libpython3.3m.so.1.0)
==7604== by 0x4EB7432: ??? (in /usr/lib64/libpython3.3m.so.1.0)
```
We are not taking into account transfer annotations when marshaling GValues to Python:
https://git.gnome.org/browse/pygobject/tree/gi/pygi-struct-marshal.c?id=3.13.91#n377
### Blocking
* [Bug 693111](https://bugzilla.gnome.org/show_bug.cgi?id=693111)https://gitlab.gnome.org/GNOME/pygobject/-/issues/81Deprecate pipe arguments to GLib.spawn_async2022-05-09T07:19:14ZBugzillaDeprecate pipe arguments to GLib.spawn_async## Submitted by Simon Feltman
**[Link to original bug (#735213)](https://bugzilla.gnome.org/show_bug.cgi?id=735213)**
## Description
GLib.spawn_async is implemented as a static binding wrapper around g_spawn_async_with_pipes(). The ...## Submitted by Simon Feltman
**[Link to original bug (#735213)](https://bugzilla.gnome.org/show_bug.cgi?id=735213)**
## Description
GLib.spawn_async is implemented as a static binding wrapper around g_spawn_async_with_pipes(). The static wrapper accepts boolean arguments for standard_input, standard_output, and standard_error. When these boolean are passed as True, the function returns pipes instead of automatically redirecting them.
Since GLib.spawn_async_with_pipes (introspected function) works fine, we should deprecate the passing of the pipe flags to spawn_async() in preference for this function. This will give us the ability to eventually get rid of the static spawn_async() bindings and be left with introspection versions of spawn_async() and spawn_async_with_pipes().
### Blocking
* [Bug 685373](https://bugzilla.gnome.org/show_bug.cgi?id=685373)https://gitlab.gnome.org/GNOME/pygobject/-/issues/78Cannot set __doc__ attribute of GObject sub-classes2023-08-03T05:15:20ZBugzillaCannot set __doc__ attribute of GObject sub-classes## Submitted by Simon Feltman
**[Link to original bug (#734926)](https://bugzilla.gnome.org/show_bug.cgi?id=734926)**
## Description
Not a huge problem but this should be possible:
```python
from gi.repository import GObject
class...## Submitted by Simon Feltman
**[Link to original bug (#734926)](https://bugzilla.gnome.org/show_bug.cgi?id=734926)**
## Description
Not a huge problem but this should be possible:
```python
from gi.repository import GObject
class Spam(GObject.Object):
pass
Spam.__doc__ = 'eggs'
AttributeError: can't set attribute
```https://gitlab.gnome.org/GNOME/pygobject/-/issues/73Rename and deprecate pygobject dunder attributes2018-03-22T15:26:35ZBugzillaRename and deprecate pygobject dunder attributes## Submitted by Simon Feltman
**[Link to original bug (#732403)](https://bugzilla.gnome.org/show_bug.cgi?id=732403)**
## Description
There are a handful of attributes pygobject exposes using Pythons double underscore followed by dou...## Submitted by Simon Feltman
**[Link to original bug (#732403)](https://bugzilla.gnome.org/show_bug.cgi?id=732403)**
## Description
There are a handful of attributes pygobject exposes using Pythons double underscore followed by double underscore naming convention (__`<name>`__). This naming scheme is reserved for Python operators and should not be used to avoid potential future clashes with Python. I recall reading in Python docs that this naming scheme should not be used in client code but can't seem to find a reference ATM. I was able to find an article which states the same thing though:
http://www.pixelmonkey.org/2013/04/11/python-double-under-double-wonder
"Never, ever, invent your own dunders — Python leaves you with a number of clean namespaces (classes, modules, etc.) for your own code. Use them! The core Python team reserved a somewhat ugly namespace for themselves — don’t trample all over their compromise by stealing their names."
Here's an initial list:
```
__gtype__
__gtype_name__
__gpointer__
__gproperties__
__gsignals__
__info__
```
The one that sticks out the most is `__info__` as it is such a generic name. Replacing the naming with a single prefixed underscore should be sufficient to avoid clashes with GI library names (which is the purpose of the special naming to begin with):
```
_gtype
_gtypename
_gpointer
_gproperties
_gsignals
_ginfo
```
Alternatively we could use a single underscore followed by single underscore: `_gtype_`, `_ginfo_`, etc...
`__gproperties__` and `__gsignals__` could probably be deprecated completely because we have Property and Signal descriptors which are cleaner anyhow.