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"
c.commit()

# 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:
Contact.added.connect(callback)

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


or


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?

Want to join the team? Want to get your pet peeve fixed? Everything will unfold on the gnome-infrastructure mailing list, so sign up there if you want to get involved!

My point is, all this talk of DVCS caused me physical harm. Discussion considered harmful, lesson learned.

A couple of interesting points were raised about the git-serve bridge which I would like to answer, regardless of what infrastructure GNOME migrates to. I should have been more clear from the start, but the bulk of the work to implement the Git protocol is happening in an upstream project called dulwich. Theres no relation to Bazaar, and might be a nice library for anyone doing Git work in python (it doesnt need to spawn git processes to operate). The code there is based on some earlier work by James Westby and its current maintainer is Jelmer Vernooij. Any code for the git-serve mapping between Git and Bazaar is getting added to the bzr-git plugin, and again i’m working with Jelmer.

I’ve written some basic responses to the common gut reactions on the Bazaar wiki.

In the context of GNOME, a more interesting question was about how to merge branches from people not using GNOME infrastructure and a different VCS to the maintainer. First of all, why arent they using us? But one interesting thing i’d like to see is a code review system with tight VCS integration. For example, using dulwich to allow people to push a branch to review board and convert it into a review automatically. (The Git protocol will send only the commits that need to be merged). Anyone can push, no plugins or setup needed by the contributor. Then we can allow people to land a merge from review-board in the browser, or merge from review-board into their local branch or even request buildbot test the branch first. git:// is a protocol. We implement lots of other protocols in the freedesktop world, lots of them far more complicated, lots of them much less open. So this doesnt scare me. Its just an efficient way of swapping patches. And of course we can reuse bzrlib for supporting Bazaar.

Most points that have been raised have a valid counter-argument if you approach them with a “we can” attitude, but going over them would likely lead to more ice slipping. I will be at FOSDEM, be sure to bring a stick.

Even if we don’t use Bazaar (and dulwich) as the platform for our core source code hosting, we can still build lots of cool tools and services around GNOME with it. If you want to help out get in touch, or get in #gnome-bzr.

We really need to start cleaning the modulesets – one of the biggest problems we had is that the properties are getting misused. “../branches/foobar” is not a module, its part of a path! This is the route to pain, misery and suffering! As I find time I hope to clean this up, but for now the JHBuild mirror seems to be working.

To start using it, just set mirror_policy to “bzr” or “git” in your .jhbuildrc. You probably want a clean slate for this – it won’t doing anything clever in terms of taking over existing SVN checkouts. Another option is

module_mirror_policy = {
  "conduit": "bzr",
  "foobar": "git,
}

I hope to get JHBuild to automate git-svn a little here too (and automatically git-svn init) where appropriate.

<snipped out the bit where i ramble about all the different options people have already suggested. me rambling FTYawn>

There is another approach. The Git protocol is quite easy. The Git pack container format is easy. The basic Git objects are easy. Who says i have to store Git packs in Git? As long as the client Git can grab packs and push packs it is happy. All other operations are local.

So lets take bzr-playground and run something that provides git:// and git+ssh:// access to the bazaar repositories. Push and pull. We’ll still have a central point from which we can view and checkout a GNOME module and the infra work can focus on a single platform. But the choice of tool i use to do my work is (partially at least) back down to me.

I am currently able to read and write the pack container format as well as speak a decent amount of the git-upload-pack and git-receive-pack protocols. It won’t be the first time i’ve serialized or deserialized git objects, so that won’t take very long. Then its just a case of storing things in Bazaar and maintaining a cache of sha1 to bazaar id. Sure, i’m trivializing here, but i am confident that this is doable.

I’m linking to the code I have so far (its an extension of bzr-git) as a gesture that this isnt total vaporware, but it’s not really anything you can try yet.

lp:~johncarr/bzr-git/git-serve

At this point im mainly interested in collecting +1’s and -1’s on the basic concept.

Why blog about this (other than its awesomeness)? Well one bit I did notice was that they have a gconf alternative called xfconf, and of course unlike our current gconf it is entirely dbus based. And, on hearing a suggestion, a rumor, a murmur that GNOME is all about the people and the community… I think it would be cool if we could work with the Xfce guys on this one. I mean their project uses GObject, dbus and has the same goal, right? I’m told we want an ORBitless desktop. So whats stopping us from sharing this part of our desktop?

If you see technical limitations of their system (I haven’t looked, I assume sanity and beauty), instead of a rant about it here why not go forth and help them out? Community, community, community.

Of course it could be that dconf or gconf-dbus (our 2 non-mainline gconf-orbit replacements) would be a good fit for Xfce too.

Heres to a *conf-dbus for GNOME 2.26.

You can see how the mirrors are currently created and updated in the vcs-mirror repository. To share in my vodka and whisky spoils for setting up git-mirror (which, despite idle threats to the contrary, i’m still waiting for) your solution should not disturb existing clones….

(And yes, that is a hg script you see).

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.

There was a second smaller talk on DVCS that was slightly more productive. Neither side has managed to provide an action plan so far. When the Bazaar and the Git advocates can come to GNOME and say “we have a plan, this is how we are migrating and this is how we are going to fix all the systems that depend on GNOME”.. then we can talk. This whole issue needs some JFDI – we can’t cry/shout until our DVCS is picked, and then expect the sysadmins to take care of it.

On a lighter note, got some swag. Quite happy with the laptop bag, and the T-shirt is quite nice. Doesn’t match the codethink t-shirts though

Now back to cleaning up the Git code so Rob doesn’t harm me.

Oh, it also shows off something I badly explained the other day. See here. Revision 5 was committed by myself, but bzr-svn also saved the –author property, attributing that code to Jelmer correctly.