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




--
https://mail.python.org/mailman/listinfo/python-list

Reply via email to