Some Things Come From Nothing

json-glib: 0.6 is out! please: download it, test it, use it. as far as I know, it has been packaged for Debian unstable, and has entered the NEW queue (kudos to Rob Bradford, esquire and fine gentleman).

debian: with the release of Hardy I decided to switch back to Debian after three years of Ubuntu. even though there are still some rough edges in Lenny, the support for laptops has definitely improved a lot and so I got back to my old love. starting from Gutsy, I found myself increasingly at odds with Ubuntu decisions and even though I upgraded my wife’s laptop to Hardy, I’m really glad I got back to Debian.

clutter/1: apparently, I’ll give a lightning talk about our reference toolkit for Clutter at this year’s GUADEC, in Istanbul. Øyvind proposed it for me because, regardless of being on the paper committee, I actually forgot the deadline for the CFPwhoops, maybe I shouldn’t have said that. :-) with the Tidy lightning talk and the Clutter guts talk given by Matthew, we decided for a high-level/low-level approach, instead of going for the usual this is teh Clutter, look at teh bling kind of talk. if you want to understand Clutter, Matthew’s talk is definitely where you want to be; as we all know:

Clutter = Clean and nice API + Performance + Portability + Integration = ♥

from my Clutter talk at FOSDEM

so, if you want to know how Clutter creates love, get to Istanbul this July. :-)

tweet: I started eating my own dogfood. Tweet is by no means complete or even guaranteed not to turn you into a goat and eat your breakfast — but now it works well enough for reading your own timeline and sending new statuses; and it doesn’t require trunk of anything any more, thanks to a Tidy transplant. I’m using Tweet as a way to see what kind of API is needed to properly integrate a Clutter canvas into a GTK+ application: colors, fonts, etc. if you want to try it out, contribute or just mock my insanity:

  git clone git://github.com/ebassi/tweet.git

clutter/2: we’re really close to a 0.7 release, which will mark the beginning of the slushy phase of the API; as far as documentation goes, we’re in pretty good shape already, at 93% for the Clutter namespace, and another 80% for the Cogl namespace. bindings will need to be updated — but the amount of new API is not that big, so it’s not going to be a long wait. I’m making a note here: huge success.

The Laws Have Changed

This week I got an invite for trying out Github beta. Github is a nice service providing some space and tools to set up git repositories for open source projects.

Obviously, setting up HTTP (dumb) read-only git repos is doable on any box connected to the intertron by merely copying the repository; the nice bits of working with git, though, like pushing branches and tags, or fast cloning through the git: protocol are somewhat harder to set up, so anything that relieves you from actually doing this kind of work should always be welcome.

Github not only provides you with that: it also gives you an incredibly nice web interface; a wiki; the ability to easily track other projects through RSS feeds; the ability to easily set up a “fork” of another repository, thus easing the pain of setting up personal development repositories for contributors.

I decided to try Github by moving there JSON-GLib‘s development git repository, plus some branches and the release tags. The operation took me approximately ten minutes, including the account creation, and it was all very easy and very well explained.

At the moment, Github is in beta1 and there are lots of projects starting out; if anything happens, cloning out with full repository history is also a nice feature of git, so I guess that side is covered as well. Bugs and feature requests are now handled using wiki pages, so if I’d have to make a request to the guys at Logical Awesome then it would be: dudes, move to a serious bug tracking system – wikis don’t scale for that (believe me: been there, done that).

All in all, it’s a great service – the way SourceForge should have been, if technology allowed it at the time and if they didn’t choose to reimplement the damned BTS and mailing list archives with something that can only be described as “made of fail”; and if they plan to make me pay a reasonable fee, it’s fine for me: Github’s UI alone is worth it.

  1. If anyone is interested to try it, I have two invites an invite left to give out invites are now all gone []

Porcelain

Today I committed to Clutter trunk ClutterScript, the initial support for defining the scenegraph using external files. You can think of it as the GtkBuilder equivalent for Clutter.

During the 0.3 development cycle we considered using XML and JSON, and opted for the latter because while XML is quite easy for applications to write, JSON is more geared towards human to read1. Also, JSON syntax is really parser-friendly, with only three barewords and six symbols.

Another nice thing about JSON is that many high-level languages already have some JSON module, so manipulating data streams would be quite easy for, let’s say, Perl or Python before feeding those streams to Clutter.

Defining a simple scene with JSON and ClutterScript is quite easy:

{
  "id" : "main-stage",
  "type" : "ClutterStage",
  "fullscreen" : true,
  "children" : [
    {
      "id" : "red-button",
      "type" : "ClutterRectangle",
      "x" : 100,
      "y" : 100,
      "width" : 100,
      "height" : 100
      "color" : "#ff0000ff"
    },
    {
      "id" : "green-button",
      "type" : "ClutterRectangle",
      "x" : 300,
      "y" : 100,
      "width" : 100,
      "height" : 100
      "color" : "#00ff00ff"
    },
    {
      "id" : "blue-button",
      "type" : "ClutterRectangle",
      "x" : 600,
      "y" : 100,
      "width" : 100,
      "height" : 100
      "color" : "#0000ffff"
    }
  ]
}

This will draw a red, a green and a blue square, 100×100 pixels of size, inside a full screen stage.
You can then retrieve the "main-stage" object (as well as any other object using its id) and connect signals and manipulate them with the usual Clutter API.

At the moment ClutterScript is not 100% complete – I still need to add support for defining behaviours (mostly a matter of defining an object syntax); complex properties parsing; merging (and, possibly, unmerging) of “snippets” of objects. Plus, obviously, more sanity checks in the scene building code.

To parse JSON there are a few C libraries, but I opted for writing a GObject-based one – which, in one of my usual moments of lack of originality, I called JSON-GLib. Clutter uses an in-tree copy because I might need API changes to make Clutter parsing code easier, but the library is already auto-tooled, tested and 100% documented (it is missing GObject deserialization, but that will have to wait). JSON-GLib is released under the terms of the LGPL and it’s available in my personal git repository, which you can clone with the usual:

  git clone http://folks.o-hand.com/~ebassi/git/json-glib.git

Update@2007-10-09T15:07+0100: Just landed in trunk: defining behaviours (not every type, complex types like the path-based ones are still to be implemented), merging tests and more sanity checks. Defining a rotate behaviour boils down to:

{
  "id"          : "rotate-behaviour",
  "type"        : "ClutterBehaviourRotate",
  "angle-begin" : 0.0,
  "angle-end"   : 360.0,
  "axis"        : "z-axis",
  "direction"   : "cw",
  "alpha"       : {
    "timeline" : { "loop" : true, "num-frames" : 300, "fps" : 60 },
    "function" : "sine"
  }
}

Really soon now: all behaviours, complex properties and more.

  1. obviously nothing prevents adding an XML parser, and use both []

When the Levee Breaks

Yesterday I decided to start working on the porting of the Gtk2::SourceView Perl module to the new upstream API. For my convenience, and because I know I’ll probably screw up, I decided to use a local git repository so I can experiment with all the branches I want before hitting CVS. Yes, you read that right: the Perl GTK+/GNOME bindings still use CVS on SourceForge.net1. Thus, I decided to import the whole gtk2-perl repository into a git one using git-cvsimport, and – lo and behold – after four hours of checkout, I got it on my machine, complete of full history.

The layout of the bindings modules is composed of a single CVS module and all the Perl modules are inside it; this is far from optimal with git2, so I proceeded to split up each Perl module into its own repository, with the help of git-filter-branch – a new command taken from the Cogito suite and added to the 1.5.3 release of git.

The filter-branch command is extremely powerful: it rewrites the history of a repository (which is a destructive operation) by passing a filter function on it. It has a set of predefined filters and contexts of operations, so what you need to do to split out a sub-directory into its own repository is call:

  $ git filter-branch --subdirectory-filter directory refspec

and after that you get all the files filtered out marked as new or modified, so you can use git reset --hard to get rid of them, and have your sub-directory contents as the only recognised content of the repository.

Unfortunately, you can’t really filter out a direct import of a CVS repository: git-cvsimport stores branches and tags, and filtering will most likely create dangling objects; so, what I did was cloning the original repository, to get rid of the local branches, and remove all the tags:

  $ git clone --no-hardlinks /tmp/gtk2-perl Gtk2-SourceView.git
  $ for TAG in `git tag`; do git tag -f -d ${TAG}; done

The --no-hardlinks switch is important for later – I have to thank Ricardo Signes for this tip; in short: it makes git use real copies instead of hardlinking files when cloning a local repository, and will make the garbage collection and pruning phases actually work and prune the unused objects from the git database.

At this point, I just filter-branched and reset:

  $ git filter-branch --subdirectory-filter Gtk2-SourceView HEAD
  $ git reset --hard

and then called:

  $ git gc --aggressive
  $ git prune

and finally obtained my local git repository of the Gtk2-SourceView module from the original CVS repository – with all the history on HEAD preserved. The good part is that the entire set of operations is very repetitive, so it’s suitable for scripting3. Yey for git! :-)

  1. there has been talk about moving them to GNOME CVS, then to SVN, but in the end the maintenance burden would be too high, and some of the members of the team would need at least SVN accounts anyway []
  2. or any other SCM software that is not CVS, for that matter []
  3. I did write a small script which extracted every Perl module sub-directory into its own git repository – but it’s mostly 50 lines sugarcoating the core 5 lines of actual work []