On Monday, I was exposed to US-style motivational speaking and team building. There was an element of forced enthusiasm in the team building company employees. Overall it was okay, but frustrating at times.
At the end they taught us to punch through flaming boards of wood. I was only on fire for a little while.
I arrived in San Francisco today for the Canonical company conference. Seems like a nice place, and not too cold 🙂. So far I’ve just gone for a walk along Fisherman’s Wharf for a few hours. There look
On the plane trip, I had a chance to see Last Train to Freo, which I didn’t get round to seeing in the cinemas. Definitely worth watching.
Like a few other states, Western Australia does not do daylight saving. Recently the state parliament has been discussing a Daylight saving bill. The bill is now before the Legislative Council (the upper house). If the bill gets passed, there will be a 3 year trial followed by a referendum to see if we want to continue.
I hadn’t been paying too much attention to it, and had assumed they would be talking about starting the trial next year. But it seems they’re actually talking about starting it on 3rd December. So assuming the bill gets passed, there will be less than a month til it starts.
If it does get passed, then everyone will need to get time zone data updates for their computers (if they’re in WA, or communicate with people in WA). Curtains will fade! Cows will be confused! It will be chaos!
I published a Bazaar branch of the Nautilus obex method here:
http://bazaar.launchpad.net/~jamesh/+junk/gnome-vfs-obexftp
This version works with the hcid daemon included with Ubuntu Edgy, rather than requiring the btcond daemon from Maemo.
Some simple instructions on building it:
svn checkout https://stage.maemo.org/svn/maemo/projects/connectivity/osso-gwobex/trunk osso-gwobex
The debian/ directory should work fine to build a package using debuild.
bzr branch http://bazaar.launchpad.net/~jamesh/+junk/gnome-vfs-obexftp
There is no debian packaging for this — just an autogen.sh script.
It should work on other distributions, but I haven’t tried it. The main requirement is bluez-utils 3.7, and that -x is passed to hcid to enable the org.bluez.RFCOMM interface.
Still to do is cleaning up the obex:/// listing of bonded devices, so that it serves desktop entries rather than symlinks, so that it is usable in Nautilus. This would also make it easier to show the device names to the user and get nice icons.
In my previous entry about using the Maemo obex-module on the desktop, Johan Hedberg mentioned that bluez-utils 3.7 included equivalent interfaces to the osso-gwconnect daemon used by the method. Since then, the copy of bluez-utils in Edgy has been updated to 3.7, and the necessary interfaces are enabled in hcid by default.
Before trying to modify the VFS code, I thought I’d experiment a bit with the D-BUS interfaces via the D-BUS python bindings. Most of the interesting method calls exist on the org.bluez.Adapter interface. We can easily get the default adapter with the following code:
import dbus
bus = dbus.SystemBus()
manager = dbus.Interface(
bus.get_object('org.bluez', '/org/bluez'),
'org.bluez.Manager')
adapter = dbus.Interface(
bus.get_object('org.bluez', manager.DefaultAdapter()),
'org.bluez.Adapter')
At this point, it is possible to perform discovery:
import dbus.glib
import gtk
def remote_device_found(addr, class_, rssi):
print 'Found:', addr
def discovery_complete():
gtk.main_quit()
adapter.connect_to_signal('RemoteDeviceFound', remote_device_found)
adapter.connect_to_signal('DiscoveryCompleted', discovery_completed)
adapter.DiscoverDevices()
gtk.main()
It is also possible to configure periodic discovery, which will send signals about devices that get found, disappear, or change name, so we could easily implement the obex: directory listing that shows all the devices found that support OBEX-FTP. One thing that isn’t clear from the API documentation is what happens if multiple programs try to start or stop discovery at the same time. It looks like the second program will get a org.bluez.Error.InProgress error when it tries to begin discovery. Ideally discovery would stay active til the last program interested in the results closed. Maybe I am misunderstanding it a bit and you can actually use the interface in this mode.
When we want to actually do OBEX-FTP with the device, we can establish the rfcomm connection:
rfcomm = dbus.Interface(
bus.get_object('org.bluez', manager.DefaultAdapter()),
'org.bluez.RFCOMM')
# will return e.g. /dev/rfcomm0
devname = rfcomm.Connect(bluetooth_address, 'ftp')
# communicate with the phone via the new rfcomm device
rfcomm.Disconnect(devname)
So it should be possible to modify obex-method to function with only the daemons included in Ubuntu Edgy. All that’s left is to do the actual work 🙂.