JavaScript is the best choice going forward for a lightweight glue language between the great C libraries that the GNOME project has produced. Python, while great and my language of choice, carries a lot of baggage that makes it hard to be a complete fit going forward. For instance many of the compromises we have to make when using GI in Python means we no longer take advantage of some of the nicer features of the language. In other-words GNOME programming in Python often veers from “the Python Way”.

Now that finally there is some consensus, we can all move forward and GNOME can concentrate on making a kick ass development platform that can focus on the little things like great docs, best practices and tight language integration. They can do all this without the distraction of “but that isn’t how it is done in <insert your favorite language here>”. Seriously, if someone brings that up in a discussion they can now be thoroughly ignored.

Does that mean other languages are left out in the cold? Certainly not. Python still remains one of the best languages supporting GI and GNOME. That will continue as long as people are interested in contributing to the effort. It will even gain from the documentation work being done by the JavaScript guys.

Day in and day out I work with many computer languages. While I may hold my favorites close to me, I have also come to recognize there are times when even languages I may not be fond of are a better fit for a particular problem space. Like it or not, JavaScript is pervasive and really is the way forward for rapid development in GNOME. It must have been a tense moment when the decision was made but I applaud that a hard decision was made and we can now move forward with a clear vision of delivering a great developer story for the GNOME desktop.

Basically it is a bunch of HTTP calls to establish the stream and then it is simply a number of packets airplay headers consisting of either H.264 video stream (of the desktop), H.264 extra data or a heartbeat.  It also uses a separate port to do NTP time synchronization every 3 seconds.  Seems pretty straight forward and fun project for someone to get their hands dirty with.

Note, that I am also willing to help with this if someone can tell me what pads need to be created and how I would go about hooking them up to get the correct stream.  E.g. how do I do the http setup, hook in an NTP service and provide headers for h.264 streams and sync the whole thing up.  I also plan on writing the UI bits as a GNOME 3 plugin complete with avahi auto-discovery if we can get this working.

In any case it is time to take a risk and the opportunity presented itself.  I wouldn’t leave Red Hat for just any company but the team they are putting together at Stackdriver along with the management’s views on how a startup should be run convinced me that it is a great bet to make.

I will be transitioning out of Red Hat at the end of the month and starting full steam at Stackdriver.  Rest assured I will still be using GNOME and Fedora as my development platform and will continue to be part of the community though less visible.  I am also coming back to Python land after my brief stint with Ruby.  I have learned to like Ruby even while muttering under my breath on the lack of some documentation and strange design choices here and there.  But I digress.  It will be nice to get back into Python development.

To all my Red Hat coworkers and friends, lets make sure we keep in touch.  Lately it occurs to me what a long, strange trip it’s been.  Keep on truckin’!

Bus Selection

The bus selection screen lists out the standard buses and allows you to add an arbitrary address.  Notice we are taking UI cues from Documents, Boxes and all the other GNOME 3 application designs.  The idea behind the statistics and status icons is to give a quick overview of the data going over the buses.  This becomes more important as we drill down as it should allow quick identification of any battery draining services that are waking up too much.  The idea is to show which services and buses are currently and historically (since d-feet was started) are active or idle.

Notice the bookmark side bar.  I haven’t quite fleshed this out but the basic idea is a place where buses, services, interfaces and methods, etc. can be dragged and grouped for quick access per project.  Even more interesting is being able to group services so that they become the only ones that get monitored which we will get to later on in the post.

Service Selection

Services are selected much in the same way buses are except you can’t create new services.  Here we see the statistics and status which are the similar to the bus selection screen except they are restricted to the particular service.  I like the placement of the status icon much better here in the upper left instead of on the icon itself.  Status should also indicate if a service is not activated and give the option of activating it, perhaps with a play icon in the upper right.  Notice that the user should be able to drag and drop a service into the bookmark panel and they should be able to coexist with buses there.  Services without bus names should be excluded by default but be able to be turned on  via a context menu option.  Hovering over a service should perhaps bring up a quick details box for better identification of services with only unique names.

Service Browsing

Getting rid of the treeview means we can operate on a wider variety of devices.  The pane view allows us to restrict to one pane at a time for smaller devices and multiple pane for large screen devices.  Much more useful information can be displayed in this way.  Like the services without a bus name common interfaces such as Introspectable and Properties are hidden by default.  Instead we opt to use those interfaces to display more useful information such as the actual properties.  Any items in the pane except for the details pane should be draggable to the bookmarks panel.  The bookmark panel itself should have better visual separation than shown here.

Bustle Monitoring

Ok so this is pretty much stolen from my friends at the Bustle project.  However there is no reason there needs to be two tools for debugging D-Bus.  I just never had an idea of how to seamlessly integrate both tools.  To start with I see this as simply monitoring on the bus and individual service level but with the named bookmark panel we can perceivably use that to group together the services and interfaces that we are interested in monitoring and kick off a monitoring session from there.  Ideally the output of the monitoring session can be used to further drill down to set up the next session, e.g. remove messages that are just cluttering the output.

Conclusion

This is all pie in the sky and requires someone to pick it up and run with it, further fleshing out the design and implementing the bits.  D-Feet was originally a one-off I wrote designed to show D-Bus Python’s access to even the low level bits of D-Bus.  It was also an exact visual representation of the message structure hierarchy/pseudo object model  which some people had trouble conceptualizing in the early days of D-Bus.  Having served its purpose well it is time to rethink D-Feet as a complete D-Bus debugging and monitoring tool with a modern interface that can run on multiple devices or as a remote debugger.  I myself do not use D-Bus these days or have any time to work on such an ambitious project but hopefully this post will kickstart a couple of people who have been looking for a something to work on.

, a photo by John (J5) Palmieri on Flickr.

I had some duck in a cream sauce over toasted bread. I don’t have a picture of it but Emily had sliced cured beef similar to Iberico Ham over toasted bread with a high quality EVOO drizzled on top.

a photo by John (J5) Palmieri on Flickr.

This was the dish the chef made for Colin. It was a tower of sautéed vegetables topped with goat cheese and caramelized onions with EVOO and a balsamic reduction drizzled on top.

I was quite impressed and the small dish sizes left room for some desert with the mandarin orange sorbet being my favorite. The complete meal left us completely satisfied.

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.