Posts Tagged ‘Conduit’

Playing with RDF

Friday, May 15th, 2009

I’ve been playing with the master branch of tracker and i’m loving it – it looks like its finally reached the stage where I won’t just turn it straight off after a fresh install.

It now brings GNOME an RDF store with a SPARQL interface. Powerful joo-joo, but kinda scary if you haven’t seen it before. Most conversations about it lead to words like graphs, triples, ontologies… My eyes start to gloss over.. I need to learn by doing. So i’ve been playing with writing some python wrappers to hide tracker and just provide a familiar pythonic interface.

Any object type that tracker knows about will be available in python via the wonders of introspection. All properties of the class are available, with docstrings explaining the intent of the property and its type. Obviously you can get, set and delete and do simple queries. And behind the scenes are SPARQL queries in all their glory. Theres a lot still to do, but enough done that I can synchronise my address book to Tracker with Conduit (see my tracker branch).

So far it looks something like this (but its subject to very rapid change):

import tralchemy
from tralchemy.nco import Contact

# add a contact
c = Contact.create()
c.fullname = "John Carr"
c.firstname = "John"
c.nickname = "Jc2k"

# find all the people called John
for c in Contact.get(firstname="John"):
  print c.uri, c.fullname

# subscribe to any contact changes
def callback(subjects):
  print subjects
Contact.notifications.connect("SubjectsAdded", callback)

# Will probably be just:

While get() is a nice way to do simple queries, what if you wanted to do something a little more complicated. It always feels messy when you have SQL or SPARQL nested in other code. Existing SQL ORM tools are a great place to start at avoiding this, but i quite like the LINQ style generator-to-SPARQL. Something like:

q = Query(Contact.firstname for Contact in Store if Contact.nickname == 'Jc2k')


q = Query(c.firstname for c in Store if c is Contact and c.nickname == 'Jc2k')

Hmm decisions. Hope to implement similar abstractions in JavaScript, C# (via LINQ) and Vala (via Magic). Anyone wanna share their cloning tech?

Thank you :-)

Thursday, August 14th, 2008

Yesterday I received some post. How is this blog worthy? Well after LRL, I was approached by people offering me test devices for adding Conduit support. Gareth Qually has donated a Handspring Treo 90 and John Connelly has loaned a Tungsten T3 and a Treo 650. All of the devices arrived yesterday and are now sat on my desk. How awesome are these guys! *Happy Dance*

A little closer to home (well, office), Rob Taylor got a new phone and donated his old M600i.

At the moment this means my pile of dedicated test devices looks like this:

  • Sony Ericsson P900
  • Sony Ericsson M600i
  • Dell Axim X5
  • Orange SPV C500
  • Palm Tungsten T3
  • Handspring Treo 90
  • Treo 650

I also have a Nokia 3310, but i’m not sure I can even connect it to my PC…

I also have ad-hoc access to Rob’s new phone, as well as my own SPV E650, Nokia N810 and iPod video. These are in regular use so won’t find themselves strapped to the Conduit test suite any time soon (but it does mean that some of this stuff will get tested by ‘users’ too :-))

Fun times ahead getting all this stuff to work :-)

Conduit and Accessibility

Monday, August 4th, 2008

This blog post is a friendly note to application maintainers out there to think carefully about how accessible your software is, especially when using non-standard widgets or canvases. Accessibility is important and it can also be hard. So think about it early and think about it often. Below are some notes from in the trenches, and if you think about a11y from the beginning things won’t end up this way for you.

One issue to rise out of the current module proposal discussion is Conduit and its accessibility. In order to be a good GNOME application, Conduit needs to be accessible. The use of a canvas to render shiny goodness manually means that we sacrifice lots of ready made accessibility.

Conduit has two major issues on the accessibility front. Can I control it without using a mouse? And can I tell what is happening when i’m using a screen reader? Sadly, the current answer is no and no. Having decided to change this, I’ve spent the weekend looking at how to pass more useful information to the accessibility infrastructure.

We use GooCanvas, which is actually already accessible. Each item that is added to the canvas is available to accessibility tools, be it a raw canvas item or a gtk widget. Basic information such as its size and position is exposed without any effort on the part of the application author. Whilst experimenting, I have hit the following limitations:

1. Without implementing more ATK interfaces, the only Conduit relevant information I can expose is a name and a description for each object. Its not easy to implement new interfaces without throwing away the existing interface. This is really quite limiting, and I don’t think it will make for a good enough user experience. (I don’t consider this a GooCanvas bug, but instead something that Conduit needs to fix on its own).

2. GooCanvas doesn’t seem to implement the children-changed signal. In testing this has meant that accerciser is unaware of changes on the canvas, and i’ve needed to keep restarting accerciser.

So GooCanvas needs a patch to fix children-changed. Lets defer that to later, i’ll look at it early in the next cycle. For now I need to work on fixing Conduit. Hopefully I can derive from the existing Goocanvas ATK objects and extend, as opposed to rewriting it all. Sadly not, the GooCanvas accessibility code isn’t available from python, so I need to re-implement everything. Again, potential patch to pygoocanvas deferred to early next cycle.

From reading the Devhelp for ATK, it seems that I just need to implement an atk.Object (and assorted interfaces) and an atk.ObjectFactory for each accessible GObject I want to have. So how do I implement an interface in python? My initial thought was that I would just have to derive from them:

>>> import gobject
>>> import atk
>>> class Foo(atk.Object, atk.Component):
...    def some_method(self, param):
...        pass

Is it enough?

>>> gobject.type_interfaces(Foo)

GObject doesn’t seem to know that I want to implement an interface. So my code is not enough. After poking this for some time it turns out there are two fundamental pieces of fail with my first attempt.

At some point, pygtk claimed to automatically register things for me. In this case, maybe more generally, this is not the case. I need to register my class with the GObject type system:

>>> gobject.type_register(Foo)
>>> gobject.type_interfaces(Foo)
[<GType AtkComponent (136469760)>]

Victory! At this point I was hoping my code would spring to life, but it didn’t. Poke, poke, poke. When overriding a GObject method from python or implementing an interface you need a do_ prefix. Presumably this is to make the introspection foo a little less scary. So I needed:

>>> class Foo(atk.Object, atk.Component):
>>>    def do_some_method(self, param):
>>>       pass

Once you have implemented your accessible object, you need an accessible object factory, and you need to register it with the default ATK registry. I’m leaving some bits out here, but basically:

>>> class FooFactory(atk.ObjectFactory):
...     def do_create_accessible(self, obj):
...         return Foo(obj)
>>> gobject.type_register(FooFactory)
>>> atk.get_default_registry().set_factory_type(GooFoo, FooFactory)

Now when ATK encounters a GooFoo object it should ask FooFactory for an accessible version of it. It will get a new Foo object.

Unfortunately this is not what happens. !”£$. A new FooFactory is instanced, and then a GCritical fires, because create_accessible isn’t happening and something is then trying to ref a null. Sigh. Epic Fail. After examining pygtk, it turns out that the create_accessible method of atk is blacklisted when bindings are generated. I unblacklisted it and encountered a nice compile error. If you poke around (or ask Rob), you’ll see that create_accessible is defined without a self, its essentially a @staticmethod. This is an edge case that the code generator doesn’t currently handle, and the wrapper ends up trying to pass too many arguments. So now I need to figure out a suitable patch for pyatk (or the code generator) before I can continue…

Big thanks to Rob for helping me with this so far, your big chunk of clue has been most welcome. You can has beer.

Syncing my phone, its actually easy

Friday, July 25th, 2008

A few days ago, I saw a blog post highlighting how difficult it can be to sync a phone on the free desktop. For a battle hardened command line user, the steps aren’t that troubling (although that example looks easy compared to some of the setups i’ve seen). Regardless, I certainly wouldn’t want to put my parents through this experience.

In contrast, after a recent mishap with my phone, restoring its address book from Evolution was trivial with the copy of Conduit SVN I had kicking around.
Conduit and WM6

I started Conduit and plugged in my phone. It appeared on the left hand side of the screen, so I dragged it and the Evolution endpoints to the canvas, and I did a sync. My address book is back.

There is more UI love to go of course. SynCE automagicness is getting there, but we can make it even better. Plus, we love HAL, and the next step is to respond to new devices and say “Hey, I know how to deal with that thingy you just plugged in” and offer to sync to some sensible defaults (Evolution for PIM stuff, Tomboy for Notes, F-Spot for Photos, Banshee/Rhythmbox for Music). And of course, the next time I plug it in.. Just sync it. Never make me press the sync button again.

The blinding future is to use PackageKit to download extra support packages like SynCE and libgpod as needed, when you plug in the device.

It works :D

Tuesday, May 6th, 2008

Spent the evening playing with network sync with N810 as server, laptop as client. It’s lovely. Looking at the logs its hard to tell what is happening when I try it the other way around but I think I just need to make the hildon version of the GUI a bit more dynamic so it can cope with sections getting added and removed at runtime.

Thomas, I owe you beer :-)

If you want to help out, 0.3.10 is available here, and i’ll see you in #conduit :-)

Trying Conduit on N810 & N800

Monday, May 5th, 2008

Sorry, no screenshots. Took a picture with my cameraphone, but it didn’t turn out very well.

If you want to give it a spin for yourself, the details are:

  • Catalogue: Unrouted
  • Web Address:
  • Distribution: chinook
  • Components: user

You will also need the Extras and Extras-devel repository.

Refresh your application list and install the conduit package. Among other things, you will get python2.5 and avahi. Its quite a big set of dependencies for now, it will get better when things stable up and we can split the conduit package into conduit-plugin-google etc.

There is a big bug screwing with a lot of dataproviders right now relating to icons. I’ll try to push a patch soon.

Conduit on N810 (I achieved something today)

Sunday, May 4th, 2008

So after a recent flurry of packaging, I turned my attention to Conduit on the N810. Most of the work is done, just a case of figuring out what bits are needed and pulling it together.

Most of the dependencies are taken care of. I needed to add the Extras and Extras-devel repositories to get python 2.5 and goocanvas. Right now python2.5-goocanvas doesn’t depend on libgoocanvas3, which IMO is a bug.

In the repositories I looked in, vobject and dateutil don’t seem to be available. These are needed for Conduit to go near VCard and iCal data. So I planned to grab the ubuntu/debian package and rebuild it for maemo. Not that easy, as I couldn’t find python-support or python-central. Damn. I’ve rolled my own python2.5-dateutil and python2.5-vobject and hope to get theses into extras or extras-devel shortly.

The Conduit package was relatively easy to fork from the Ubuntu PPA. I added a patch to set the default UI to Hildon instead of GTK, and then removed and tweaked dependencies. There are quite a few bugs to work out though:

  • Need to reboot N810 to see Conduit in menu (Packaging bug; presume there is a macro to refresh this?)
  • Conduit menu icon doesn’t work (Conduit bug; conduit/conduit script assumes bash.. which is bad).
  • At the moment, I’m installing manually via ssh/apt/dpkg.. Need a one click install file (Packaging bug)
  • Too big – remove manual and gtkui from package. (This needs changes in Conduit and Packaging, I think)
  • Too many dataproviders are showing that won’t work on N810. Shouldn’t really show Tomboy unless tomboy is installed.

I hope to address all the important problems in the morning and send something out to the Conduit mailing list so we can get some proper testing done. A second post with screenshots and quick install link will follow.

Looks shiny. Thanks very much to the hard work of thomasvm for making this possible :-)

It’s been too long…

Friday, April 25th, 2008

It’s been far too long since I last blogged. I’d always think of what I wanted to say when I couldn’t get to my blog, and then forget. Bah. So here is a catchup post.

Upgrades. I moved servers! Everything has been moved over to a dedicated server from RapidSwitch. After 1 year of excellent service, my VPS will soon get switched off for good. I’m still a big fan of RimuHosting, but I needed a bit more power (OK, I needed lots more power..). Isotoma use RapidSwitch a lot, and we get an excellent service from them so I figured i’d try them out. I now have 2.2Ghz Core2 Duo, 1GB RAM, 160GB hard drive and 4,000GB traffic. Really pleased with it so far.

WordPress also got upgraded, and i’m really loving the new control panel. Good work guys!

BuildBot. I’ve joined the Build Brigade on their quest to bring continuous integration to GNOME. My own efforts can be found here. The current solution needs to open up a port for each project, and we are trying to get it down to a single shared connection for all projects. When this is working I hope to set up continuous integration of the Debian/Ubuntu GNOME packages too.

I’m hopeful we can bring the same solution to the KDE and XFCE teams too.

Summer of Code. I will be mentoring 2 students for GNOME in this years summer of code:

  • John will be implementing SyncML support in Conduit. His deliverables include python bindings of libsyncml, conduit support of SyncML clients and servers, simplified discovery and configuration of those devices and a demo of sync between EDS and a SyncML device.
  • Alexandre will be implementing full support for the iPod in Conduit, and also improving integration with Rhythmbox. His deliverables include improved media transcoding, using GStreamer were possible, full dataproviders for audio and video support and work to provide a smooth, rounded “plugin and sync” experience for the user.

This is my first time mentoring in the summer of code, and i’m really looking forward to it.

Hardy. GNOME 2.22. I’ve just upgraded my work machine to Ubuntu 8.04 LTS, after running the alphas since nearly the beginning on my main development laptop. Very pleased with both so far. The upgrade on my laptop was smoother as it has Intel graphics.

Conduit. We are proposed for inclusion in GNOME 2.24. Exciting times. It seems clear so far that the biggest problem we have in acceptance will be a UI that really “works”. I’ve become quite fond of our current UI, but new users just can’t understand it at all. Anyone got any suggestions?

Synchronisation mit Unison und Conduit

Tuesday, January 29th, 2008

I don’t speak German, but we might be getting some German speaking visitors to Conduit shortly :-)

In Linux Magazine, Conduit Is

Tuesday, January 8th, 2008

So for the rest of the month, a slight mention of Conduit will be on the front page of Linux Magazine, in its “this month” blurb. Yay, if only they linked to our site! I think the current issue is out now, so i’m going to pop in WH Smiths at dinner and see if I can pick up a copy :-)

In other news, i’ve upgraded a few things on this box. Will be a miracle if I haven’t broken it :-(