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

• 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!!!

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.

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

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?

• 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.