J5’s Blog

I don’t do much GNOME work these days but since I was just at GUADEC and Thomas Bechtold started porting D-Feet to PyGI, I decided to do a quick design on how D-Feet could be made to integrate better with GNOME 3 and also become more useful. I’m also out of the loop on the whole Maemo project forks so excuse me if I should have been using a different project name in the mockups to show the concept of external embedded D-Bus monitoring.  I don’t have time to do the actual work but perhaps this can be a starting point for those who want to bring D-Feet up to date with the current state of GNOME.

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.