Replacement for pygtk?
Liste guru
digitalfantasy.it86559 at digitalfantasy.it
Sun Sep 6 03:36:55 EDT 2020
Il 06/09/2020 06:20, Michael Torrie ha scritto:
> On 9/4/20 3:24 PM, Grant Edwards wrote:
>> I assume that difference is because pygtk was hand-written and gi is
>> built auto-magically using SWIG or something like that?
> Essentially, yes. Although pygobject does not use a tool like swig to
> generate static wrappers. Rather it uses the GTK introspection API to
> ask gobject's for their methods and attributes, and then marshalls and
> calls them at runtime. So you can use pygobject with any GObject-based
> binary library, not just GTK+. Hope that makes sense.
AFAIK, from the source code / include files a .gir file is
generated (an xml with all the functions, parameters and info).
For example for a simple rectangle_int(x. y. width, height) in
cairo you have:
<record name="RectangleInt" c:type="cairo_rectangle_int_t"
glib:type-name="CairoRectangleInt"
glib:get-type="cairo_gobject_rectangle_int_get_type">
<field name="x" writable="1">
<type name="gint" c:type="gint"/>
</field>
<field name="y" writable="1">
<type name="gint" c:type="gint"/>
</field>
<field name="width" writable="1">
<type name="gint" c:type="gint"/>
</field>
<field name="height" writable="1">
<type name="gint" c:type="gint"/>
</field>
</record>
From this file a .typelib is generated (a binary, compact
representation of the data) and the gi library, using this file and the
.dll/.so, creates the correct bindings and function for the language you
use (at runtime).
Switching from Gtk 3.22 to Gtk 3.24 (or a new 3.26) is only a
matter of using the new .typelib/.dll with your version of gi, at least
until the gi folks puts the handling of the default values for parameters :)
So with the gi package for your python (say 3.5.10) you can use all
the Gtk versions, you don't have to recompile for example Gtk 3.24.13
for your python/gi version.
To have all the Gtk works with python 3.8 you have only to port /
build the gi part (and on windows make some magic to handle the new path
handling for the .dll search/load location, but this is another story).
With best regards
Daniele Forghieri
More information about the Python-list
mailing list