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

Thanks to Carlos Garnacho’s recent work with the evdev driver and Gtk+ along with Peter Hutterer’s work on getting  the multitouch situation sorted out inside of X, not to mention everybody else who has contributed to the effort, I was able to get Multitouch working on my Fedora 13 powered Lenovo T410s.

All the following instructions relate to those who have N-Trig multitouch devices. Mileage may vary with other devices. To start playing around with multitouch in Fedora today you will need

• my evdev multitouch RPM packages built from Carlos’ branch
  • Warning: this package obsolete xorg-x11-drv-evdev so you will no longer get updates from the Fedora repo
  • Note: I’ll provide a yum repo for my packages once Koji is up and running again, for now if you don’t have an X86_64 machine you will need to rebuild the source rpm.
• If you have a N-Trig device you will also need to get the kernel Kyle built which has a fixed N-Trig driver (hopefully this will show up in an update soon).
• You will also need Carlos’ xorg.conf snippet. This is again for the
  N-Trig driver but should be easily modifiable for other devices
• To play with multitouch you will need the latest Gtk+ from the xi2-playground branch

I recommend building Gtk in a jhbuild environment or at least don’t install it since it is the unstable 3.0 branch. Once the multitouch stuff has been backported to 2-20 branch I will start providing packages. I take no responsibility for the breakage of anyone’s machine due to replacing such a major system package. Thankfully, if you run inside of jhbuild you can play around all you want without fear of breaking your system. Another option might be to run inside an virtual machine but I am not sure if multitouch events will propagate correctly yet.

If you want to play with some demos you will find them inside the tests/multitouch directory of Gtk. Have fun and ping me with any issues you have. It might be nice if we got this working for Fedora 14. The pieces are certainly falling into place.

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

Is this going to happen?

First off this is a highly unlikely scenario. The planets would have to align, Qt would have to go LGPL, Nokia would have to loosen controls on contributions to avoid a fork, the Qt team would have to accept a community which has slightly different goals and the GTK+ team would have to signal their willingness to move. We are not going to turn our back on the great work the GTK+ teams are doing and most certainly the base libraries we use such as GStreamer wouldn’t change.

What are the possible advantages?

• Less confusion for the non-insiders on what to learn and program for
• We can get rid of the whole Freedesktop common widgets talk (e.g. Print and File dialogs) which is nonsense and a distraction anyway
• Hopefully less bickering in the community meaning a more unified and focused front against larger threats
• Focus can move from the lower toolkit layers to the higher level desktop layer which really define the value differences between GNOME and KDE
• Easier technology sharing

Note that these are all only possible advantages and may not even happen even if there was a move.

 What are the possible disadvantages?

• More bickering on how to write applications (who’s approach to usability wins out?)
• Less focus and a return to writing applications without a shared guideline (just look at old XLib interfaces – almost like snowflakes)
• A loss of identity
• Loss of amazing GTK+ developers who may feel abandoned
• Splintering of the community so we have parallel GTK+ GNOME and Qt4 GNOME development
• Screwing ISV’s who bank on GTK+’s stable interface
• GTK+ isn’t just a license – we would be losing a lot by switching away from the codebase
• Falling into the growing pains GTK+ 2.0 brought GNOME and Qt4 is still bringing KDE
• A loss of activity at Freedesktop.org which is actually sometimes useful in producing dialogue and shared practices
• A loss of control over the direction of the toolkit effecting the quality and feel of the GNOME desktop
• Really a lot of development is moving to the web – will toolkits be important enough to warrant the pain of the move

What this wouldn’t be

This wouldn’t be a merging of GNOME and KDE.  Each community has a different idea of what constitutes a usable desktop and Qt would simply be an implementation detail bellow GNOME.

Conclusion

This is pretty much a pipe dream.  It solves some issues while creating a whole host of different ones.  I’m not going to advocate it other than seeing what peoples reactions are.  On the flip side if the work was put behind it, the planets aligned, and both communities came to an agreement I wouldn’t object to the arrangement.  Needless to say, I’m not holding my breath nor would I be elated or saddened if it did or did not happen. To me it is all what is best for Linux, GNOME, Free Software and the wider market. It is unclear what direction would be best (any claims to that knowledge would be suspect) but honestly and actively looking at the possibilities is a useful activity, however remote. People reading should not put their “hopes and dreams” on this or believe it to be more than it is.