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 .
When I got my new laptop, one of the features it had that my previous one didn’t was Bluetooth support. There are a few Bluetooth related utilities for Gnome that let you send and receive SMS messages and a few other things, but a big missing feature is the ability to transfer files to and from the phone easily.
Ideally, I’d be able to browse the phone’s file system using Nautilus. Luckily, the Maemo guys have already done the hard work of writing a gnome-vfs module that speaks the OBEX FTP protocol. I had a go at compiling it on my laptop (running Ubuntu Edgy), and you can see the result below:
Browsing files and viewing images stored on my phone
There are a few rough edges:
I don’t have any ready made binaries for others to try at this point. Below are some notes for anyone else who wants to try building it:
With a little bit of work, this would fit into the main Gnome desktop quite well. When talking to Bastien a while back, he said that the extra dbus daemons shouldn’t really be necessary, so it might be worth trying to bypass them.
Earlier in the year, we migrated the bugs from bugzilla.ubuntu.com over to Launchpad. This process involved changes to the bug numbers, since the Launchpad is used for more than just Ubuntu and already had a number of bugs reported in the system.
People often refer to other bugs in comments, which both Bugzilla and Launchpad conveniently turn into links. The changed bug numbers meant that the bug references in the comments ended up pointing to the wrong bugs. The bug import was done one bug at a time, so if bug A referred to bug B but bug B hadn’t been imported by the time we were importing bug A, then we wouldn’t know what bug number it should be referring to.
The solution we used was to just insert a link to the bug watch URL (e.g. https://launchpad.net/malone/bugtrackers/ubuntu-bugzilla/$BUGID), which allowed people to find the referenced bug, but was a bit ugly.
Today we ran a fixup script to remove these bug watch URLs from comments and rewrite the old Bugzilla bug numbers to the current Launchpad bug numbers. This cleans up the old imported bugs a bit so they fit in better with the bugs entered directly into Launchpad.
I’ve been testing out Ekiga recently, and so far the experience has been a bit hit and miss.
Even though there are still a few warts, Ekiga shows a lot of promise. As more organisations provide SIP gateways become available (such as the UWA gateway), this software will become more important as a way of avoiding expensive phone charges as well as a way of talking to friends/colleagues.
Thought I’d post a followup on my previous post since it generated a bit of interest. First a quick summary:
The firefox bug is only triggered in the slow, manual glyph positioning code path of the text renderer. This only gets invoked if you have non-default letter or word spacing (such as justified text). In this mode, the width of the normal glyph of the first character in the ligature seems to be used for positioning which results in the overlapping text.
It seems that the bug may be fixed in the Firefox 1.6 series, but if that fix can’t be backported easily in time for Dapper, it might be easier to switch to a different default font that doesn’t contain the ligatures (such as Bitstream Vera). That would certainly reduce the chance of the bug occurring.
Ran into an annoying Firefox bug after upgrading to Ubuntu Dapper. It seems to affect rendering of ligatures.
At this point, I am not sure if it is an Ubuntu specific bug. The current conditions I know of to trigger the bug are:
If you view a site where these conditions are met with an affected Firefox build, you will see the bug: ligature glyphs will be used to render character sequences like “ffi“, but only the advance of the first character’s normal glyph is used before drawing the next glyph. This results in overlapping glyphs
It also results in a weird effect when selecting text, since the ligatures get broken appart if the selection begins or ends in the middle of the ligature, causing the text to jump around.
I wonder if this bug affects the Firefox packages in any other distributions, or is an Ubuntu only problem?
I’ve been in London for a bit over a week now at the Launchpad sprint. We’ve been staying in a hotel near the Excel exhibition centre in Docklands, which has a nice view of the docs and you can see the planes landing at the airport out the windows of the conference rooms.
I met up with James Bromberger (one of the two main organisers of linux.conf.au 2003) on Thursday, which is the first time I’ve seen him since he left for the UK after the conference.
There has been a lot of interesting stuff going on so far, some of which is already live on the production site now. Expect to see better integration with the bzr branch management features in the future.
