J5’s Blog

After being pinged in Bugzilla I finally set some time out to do a new release of D-Feet – The D-Bus Debugger.  This release was aimed at getting some of the bug fixes that have been sitting in git out into an official tarball.  The only big change is I took some time out this morning to hack up a new hi-res icon for better integration into gnome-shell.  It is based off of the system-search icon in gnome-icon-themes and I now provide a source SVG so those with better art skills than myself can fix it up a bit.

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

Since GNOME’s move to using git and the fact that upstream is where all the cool kids hack I have decided to move D-Feet to the GNOME servers to make it easier for contributors to contribute and users to file bugs.  That doesn’t mean I’m going to fix every feature request but it does mean others can help make D-Feet more useful.

I was sort of blown away that my humble little project was being used by more people than I had realized.    I was even more amazed that it was mentioned in the literature for the GNOME Developer Training Days at this year’s GUADEC.

That is not to say I think D-Feet is a particularly shining example of how a D-Bus debugging app should be written.  It kind of sucks but it does fill a niche, which is why I am starting a new design process for potentially developing a better D-Bus debugger.  Here is the hitch, I don’t want feature requests, I don’t want your bug reports (those can go into bugzilla), what I want is your workflow.  How do you debug your D-Bus apps?  What are the pitfalls, the annoyances, the most repetitive tasks that you encounter?  Please head to the Workflow Design page and add your own voice.

D-Feet is a D-Bus debugger written in PyGtk+ by John (J5) Palmieri

What a week. Get six smart people in the same room together, spend a little bit of money to get them there and get them comfortable, and good things happen. An in-depth praise for the hackfest process, which the GNOME Foundation Board has been putting more and more resources into every year, will have to wait until another blog post. Right now I want to thank our sponsors and quickly recap what was accomplished. First out sponsors, who made this possible:

• The GNOME Foundation board for providing the framework for the hackfest and travel assistance to Tomeu
• OLPC for providing us free space and all the water we could drink at their office in Cambridge.
• Canonical for making sure we were awake after the social events by providing us with coffee
• Red Hat, for feeding us with a nice Portuguese meal which we shared with the D-Conf/GSettings hackfest guys who were sponsored by Novell
• Myself, for sponsoring a couple of after hours social events to keep us all sane and allow us to discuss the future in a more social environment

I would also like to thank Walter Bender for helping us find a venue and Jeorge Castro for being the liaison between us and the Foundation. He is off to a great start as the newest Board Member.

Now to the meat of what was accomplished:

• PyGI saw its first formal release
• We suckered relative new comer Zack Goldberg into ongoing maintainership of PyGI
• Cairo, callback and virtual function support was added to PyGI
• pygobject and pygi both sprouted py3k branches on GNOME’s git servers which both fully compile and pass their unit tests (which probably means we need more unit tests). We aren’t going to move these to master for some time. But if you grab the branches and test them out the process will be much quicker.
• We were written up in Ars Technica

Right now I am porting D-Feet to use PyGI and will be testing out my D-Bus Python py3k branch after I get that up and running. D-Feet is a good test because it uses the GenericTreeModel from PyGtk as well as GtkBuilder elements. In both cases I have found places where I have had to add overrides to PyGI to complete the bindings. For instance, in the Builder I need to override gtk_builder_connect_signals which in C searches for C symbols which match symbols in the XML description file. This is useless in Python so I need to modify it to work the same way PyGTK works. Namely, by being able to pass in a dictionary or object with name/python function mappings (e.g. {’on_click’: on_click_handler}). It is not all that hard, especially since PyGI overrides are written in Python and not in C like PyGtk overrides. However I do have to get the exception behaviour correct so that might take some time.

All and all we are in excellent shape so start porting your apps and file bugs!!!

Well, I’ve gone and done it. Thanks to David Malcolm’s excellent 2to3c tool and some hand wrangling with PyUnicode objects I was able to get D-Bus Python compiling and working on Python 3. Grab the patch and start testing it out.

I’ve also tested this under Python 2.6 but it would be nice to see if it also works under Python versions < 2.6 since 2.6 has a couple of compatibility layers built in.

It is nice and balmy out here in Gran Canaria so I decided to release another version of d-feet out into the wild. This is a release of a couple of fixes which have been hanging around in git but never found their way into a tarball.

D-feet is a basic D-Bus debugger used for visualizing the API of running D-Bus applications.

What’s Changed?

• pretty print output added (Will Thompson)
• quit item added to file menu (Will Thompson)
• UI improvements (J5)
• fix for d-bus methods that return 0 (J5)
• all basic types now supported correctly (Marcel Holtmann)

Latest Tarball: http://johnp.fedorapeople.org/downloads/d-feet/d-feet-0.1.10.tar.bz2 (sha1)
Project Page: https://fedorahosted.org/d-feet/
Fedora Community Page: https://admin.fedoraproject.org/community/package_maintenance?package=d-feet

They have the details up on their web site.  Apparently it is a way of creating local applications using either Gecko or WebKit.  The remote part of the equation isn’t there and it isn’t clear if they will be perusing this angle. Right now the code only supports clients but by the look of their documentation, they are planning on creating the ability for JavaScript services which would be cool.

I just found this out after reading and article about the GNOME Mobile release.  Apparently Movial joined LiMo sometime in August and have pledged to release their Browser D-Bus Bridge as open source.  Perhaps this went over the D-Bus mailing list and I missed it but I am eager to look at the code and documentation to make sure remote sandboxed code doesn’t now have a way of breaking out of its jail.  In other words I hope they have added a permissions based system much like we have for the system bus. If they have a sane system this could really be a powerful tool.

In a local world where all your applications are installed by the user, security on the session bus doesn’t have to be tight as the application will already have all the capabilities that they might gain from using the session bus. They even have more such as rm -rf ~.  However, if web pages are now able to access the bus without a failsafe security model for access rights you would be allowing remote applications access to whatever the session bus exposes.  They would be first class citizens in a very bad way.  Depending on what services are running on the bus, information could be stolen, files added and deleted as well as other exploits.  Already gVFS runs over D-Bus and hopefully in the future we will be moving from a corba based accessibility layer to a D-Bus one which means every UI element would be exposed via the bus.

That is not to say it is all doom and gloom.   Having a browser/D-Bus bridge is very important towards moving the desktop experience forward, so much so that I was considering writing one until I saw this.  Of course there is no open code or documentation yet, at least what I could find.  I do trust them to do the right thing but it would have been nice if the development was done in the open from the start.  Can someone working with LiMo point me to the source or information of when it will be released?

That’s right, in order to support the upcomming release of GNOME 3.0 which is introducing a new tabbed interface, we’ve totally made D-Bus HIG compliant by adding tabs to the API.  No longer do you have to select a system or session bus while connecting.  Now all you have to do is select the correct tab and you are connected.  Now you might be saying, I can’t see these tabs.  Because of constraints of the D-Bus system, namely not having a GUI, we had to add virtual tabs.  Don’t worry, they are there, you just have to randomly click and eventually you will select the right bus.  Or you can simply use the new D-Bus Gtk+ bindings which exist to provide a GUI in which to display the tabs.  A word of warning though, because of Qt4’s abstraction layers when using the D-Bus Qt4 library they will show up as plasmoids.  We here at Freedesktop.org hopes this makes your D-Bus hacking a much more enjoyable experience.

Due to issues putting the re-licensing effort on hold indefinitely, it has been decided to move to 1.2.x versioning scheme. Being that 1.1.20 is considered to also be 1.2.0 and this being the second release in the 1.2.x stable series we have versioned this release 1.2.1. This release contains a number of bug fixes identified after 1.1.20:

• compiles under some older versions of glibc
• compiles without X support once again
• fix stuck server grab if dbus-launch is run in an existing D-Bus X session
• various Mac OSX build fixes added
• don’t use the broken poll call on Mac OSX
• better checks for linker flag support should allow D-Bus to link under various linkers
• exit_on_disconnect is set after the connection registers with a bus so we don’t exit if we get a disconnect during the handshake
• dicts now work correctly with dbus-send
• inotify backend is now less aggressive
• pending calls expire correctly
• memleak of uuid when the bus is autolaunched fixed

D-Bus is a message bus system, a simple way for applications to talk to one another. In addition to interprocess communication, D-Bus helps coordinate process lifecycle; it makes it simple and reliable to code a “single instance” application or daemon, and to launch applications and daemons on demand when their services are needed.

Get it now at:

http://dbus.freedesktop.org/releases/dbus/dbus-1.2.1.tar.gz

All stable development will now happen on the “dbus-1.2-branch” branch and all unstable development should happen on the “master” branch.

I got back from the BOSSA conference last week. It still is my favorite conference for just talking to people and getting things rolling. The organizers keep it small and limit the number of talks so that people can get to what they do best and just talk to each other. While I am no longer directly involved in embedded development I still feel this should be the target of most developers. A win on current generation embedded devices means improvements across the board from those devices to the desktop and even the server room. Most of my debugging and optimization techniques for D-Bus, the focus of my BOSSA talk, were gained from working with it on embedded devices. I continue to gear my work with the idea that in the near future a large portion of the people consuming those technologies will be doing so on devices that are considered to be “embedded”.