My involvement with PyGObject

That being said most of my hacking time will be spent on OpenShift related projects and while I had already transitioned out of day to day PyGObject maintainership some time ago, I will no longer have any real time to dedicate to the project (I’m actually learning Ruby right now). To tell the truth, not being able to put any more serious time into the project is one of the major reasons I decided I needed a change. There are a number of other people still contributing to the project but it is sorely in need of a lead maintainer who can do releases, keep people on schedule and ping the right people when bugs languish. I feel PyGObject is in good shape but as it begins to get more uptake bugs fixes need to be committed, edge cases corralled and the last mile needs to be traversed. I will still hang out in #python on GIMPNet and can be persuaded to look at patches or even write a few if you ping me and are nice.

Jobs

With me leaving the Fedora team there is now an opening for someone to join the team. They are looking for an all around FOSS rock star who can work in a number of different areas such as packaging, desktop and web development, and any number of miscellaneous skill your would encounter with any FOSS project. The main responsibilities would be maintaining, improving and integrating our infrastructure tools such as Fedora Community Packages web app, Bodhi update tool and Fas accounts system as well as developing tools to make it easier to contribute to Fedora. Most of the tools are written in Python so being a Python expert is a big plus as well as having worked as part of a team on any major open source project. If that sounds like fun to you send me your resume (I get a bonus if you get hired).

OpenShift is also expanding so if any of these jobs look more like your speed feel free to mail me also.

Seriously though, please do feel free to commit fixes and ping me to do releases.  I originally wrote it as a one-off tutorial because many similar projects failed to grasp the correct semantics of dealing with D-Bus messages at such a low level.  I hear D-Feet is used quite a bit but my own time is limited for such a project as I no longer use it every day.  In that respect, if someone wanted to take over upstream maintainership I am sure there is a community of D-Bus developer who would be grateful for faster release cycles and more attentive bug fixes.

Latest release: http://download.gnome.org/sources/d-feet/0.1/d-feet-0.1.14.tar.xz (sha256)

Project page: https://live.gnome.org/DFeet

I want to thank everyone who has been a part of this release, from those who reported bugs to those who submitted large patches, and also those who cheered us on from the sidelines or gave us support in other areas.  At this point in the project they are just too many to list so I won’t, in fear that I may accidentally leave people out.

Highlights Since 2.28

• New rewritten invoker is twice as fast and easier to extend and debug
• Complete break from static bindings so we may improve the core without breaking legacy APIs
• Better type handling
• Parallel installable with PyGObject 2.28 for legacy binding support (2.28 must be compiled with –disable-introspection)
• Support for function calling using keyword arguments
• Support for multiple arrays referencing a single length parameter (e.g. Clutter.Actor.animatev)
• Once again we support Windows builds with some caveats

Going Forward

As we move into another unstable cycle there are a number of goals we will strive for the next major release.

• Documentation – we jump started this at the Desktop Summit but a lot of work is needed to get this to the quality currently exhibited by the PyGTK bindings.
• Full Gtk subclassing – We are almost there but we still need support for calling C callbacks in Python to support overriding interfaces such as Gtk.Widget.for_all()
• Getting rid of all legacy marshallers – currently they are still being used for marshalling vfuncs and signals
• Cutting out the middle man – We should get rid of our dependency on GArguments and marshal directly to FFI
• Moving away from a Gtk+ focus – Clutter and GStreamer 1.0 are just as important to fully support
• Full Gio support – right now dealing with byte streams isn’t completely introspectable

ChangeLog

http://download.gnome.org/sources/pygobject/3.0/pygobject-3.0.0.changes  (1.34K)

Download

http://download.gnome.org/sources/pygobject/3.0/pygobject-3.0.0.tar.xz  (530K)
  sha256sum: ef6735792b0d44287126a6a3b181c85559849063d770506fe06848adb87ce815

http://download.gnome.org/sources/pygobject/3.0/pygobject-3.0.0.tar.bz2 (629K)
  sha256sum: 5682603c58be67e336e8cfaf19d6321158425797a7da12f646cc8706508ab95c

About PyGObject

GObject is a object system used by GTK+, GStreamer and other libraries.

PyGObject provides a convenient wrapper for use in Python programs when accessing GObject libraries.

Like the GObject library itself PyGObject is licensed under the GNU LGPL, so is suitable for use in both free software and proprietary applications. It is already in use in many applications ranging from small single purpose scripts up to large full featured applications.

PyGObject now dynamically accesses any GObject libraries that uses GObject Introspection. It replaces the need for separate modules such as PyGTK, GIO and python-gnome to build a full GNOME 3.0 application. Once new functionality is added to gobject library it is instantly available as a Python API without the need for intermediate Python glue.

Highlights

• Various deprecated API that was only needed for the static bindings have been removed which means you must recompile anything that links to PyGObject (currently libpeas and glade)
• Overrides directory variable was taken out of pygobject-3.0.pc and moved to the gi._overridesdir attribute to avoid having multiple .pc files for each version of Python.  This means third parties who install overrides need to import gi from their install scripts with the version of python they are installing for.
• Multiple arrays referencing a single length parameter are now supported along with flat GValue arrays.  This allows APIs such as Clutter.Actor.animatev to be bindable.
• Refcount crasher bug triggered when using GObject.new was fixed so glade can now import custom Python  GtkWidgets.
• Build system now works with MinGW environment in Windows.
• Python 3 now checks instance types again.
• Documents disabled since they aren’t useful yet and present parallel install issues.
• Demos were fixed up to better reflect the preferred way of using PyGObject.

ChangeLog

http://download.gnome.org/sources/pygobject/2.90/pygobject-2.90.4.changes  (20.2K)

Download

http://download.gnome.org/sources/pygobject/2.90/pygobject-2.90.4.tar.xz  (529K)
  sha256sum: 8407b6997181bbca4783798e21d7d63ca41708a6c05a3b08c953d64e7b97b2a1

http://download.gnome.org/sources/pygobject/2.90/pygobject-2.90.4.tar.bz2 (629K)
  sha256sum: 467eb39f06664fb8bbb9ab407a15b8d56a63a92ac2f0914afc8518aedd765c43

About PyGObject

GObject is a object system used by GTK+, GStreamer and other libraries.

PyGObject provides a convenient wrapper for use in Python programs when accessing GObject libraries.

Like the GObject library itself PyGObject is licensed under the GNU LGPL, so is suitable for use in both free software and proprietary applications. It is already in use in many applications ranging from small single purpose scripts up to large full featured applications.

PyGObject now dynamically accesses any GObject libraries that uses GObject Introspection. It replaces the need for separate modules such as PyGTK, GIO and python-gnome to build a full GNOME 3.0 application. Once new functionality is added to gobject library it is instantly available as a Python API without the need for intermediate Python glue.

As of now we have mostly been talking about introspection as a way to hook up existing GObject libraries to scripting languages but one of the most powerful features of Introspection is the ability to write your own C libraries inside your scripting project.  You may wish to do this for speed, or perhaps there is a feature that is not yet directly bindable via introspection.  While it is trivial to write one of these small libraries the devil is in the details and having a tutorial around would help people to dive in and play around.  What I am looking for:

• Setup – show how to setup a makefile or even a setup.py file to compile a simple library, gir and typelib files.  Make sure the build env installs all the files to the correct locations and even has a way to test changes without installing
• The C example 1 – show how to implement a simple function that takes simple input and returns output
• The C example 2 – show how to implement different types of functions including multiple output functions and memory managed types
• The C example 3 – show how to implement a gobject class with properties and other gobject features
• The Vala examples – show how to do the above in Vala
• Advanced topics could include callbacks

I’m pretty sure there may already be some Vala examples running around but the point of these tutorials would be to teach a scripter who is somewhat familiar with compiled languages how they could add lower level functionality to their project with out too much pain.  Are you up for the challenge?  Feel free to add a subpage to the PyGObject wiki.

I would like to thank the Gnome Foundation for sponsoring travel and hotel as well as space during the Desktop Summit; Openisums for supplying us with space after the Summit was over; Nemein for the excellent Fondue dinner; Collabora for the Africana food that I had to miss due to the equally excellent cocktail party at Kat and Dave’s place; and KDE for the yummy Vietnamese lunch.

Much has been sewn and much has been grown, but now it is time to go.  Another successful hackfest is in the books and now the hard work of building on our achievements begins.  But first, some beer.

The new release is available from ftp.gnome.org:

http://download.gnome.org/sources/pygobject/2.90/

What are the highlight of changes since PyGObject 2.28?

• New rewritten invoker is twice as fast and easier to extend and debug
• Complete break from static bindings so we may improve the core without breaking legacy APIs
• Better type handling
• Parallel installable with PyGObject 2.28 for legacy binding support (2.28 must be compiled with –disable-introspection)
• Fixed object array handling
• Added more overrides for PyGTK API emulation
• Support for function calling using keyword arguments
• GObject and GLib symbols can now have overrides
• All static bit removed or made private
• GVariants now work from callback returns

Do I need to port my apps from PyGObject 2.28 to PyGObject 3.0?

We tried to keep the API as close to what we were recommending for 2.28 however since 2.28 straddled both the static and dynamic APIs there are a few things to keep in mind when running under 3.0:

• don’t import pygtk – this was for static bindings only and while it may have been harmless in 2.28 it will cause conflicts in 3.0
• import gobject must be ported as from gi.repository import GObject – this was the recommended way of importing GObject but some code may still have used import gobject.  Having both will cause applications to fail because it will load the older 2.28 bindings alongside the 3.0 bindings.
• import glib must now be ported as from gi.repository import GLib – this is a new requirement and prevents the issues discussed above
• use the gi.require_version API (e.g. gi.require_version(’Gtk’, ‘3.0′)) – This is more of a recommendation as we will be outputting warnings in the future.  Due to the rapid development of certain libraries like the upcoming Gtk-4.0, it is best to specify the major version of the library you wish to target instead of relying on PyGObject to select the latest one available on the system.  This also gives helpful errors if the correct version is not installed on the user’s system.

Blurb:

GObject is a object system used by GTK+,  GStreamer and other libraries.

PyGObject provides a convenient wrapper for use in Python programs when accessing GObject libraries.

Like the GObject library itself PyGObject is licensed under the GNU LGPL, so is suitable for use in both free software and proprietary applications. It is already in use in many applications ranging from small single purpose scripts up to large full featured applications.

PyGObject now dynamically accesses any GObject libraries that uses GObject Introspection. It replaces the need for separate modules such as PyGTK, GIO and python-gnome to build a full GNOME 3.0 application. Once new functionality is added to gobject library it is instantly available as a Python API without the need for intermediate Python glue.

Introspection/Python 2 bindings requires gobject-introspection >= 0.9.5 and py2cairo >=1.10.0
Introspection/Python 3 bindings requires gobject-introspection >= 0.9.5, pycairo >=1.10.0 and Python >= 3.1

–
John (J5) Palmieri
GNOME Foundation member
johnp@redhat.com