context switch

Sincerest Forms of Flattery

tidy: they say that imitation is the sincerest form of flattery:

the actual amount of code is quite small, and it’s already available in Tidy.

challenges: Luca dared me into making a Clutter-based coverflow-like plugin for Rhythmbox, but it was Iain that picked the challenge up and wrote some basic code for it. I, on the other hand, don’t like coverflow for browsing my music collection, so I finally decided to write something for the Eye of GNOME — a Ken Burns effect slide show. it’s not at all finished, and if nobody picks it up, I’ll try and do my best to have it ready for GNOME 2.24, if EOG maintainers want it, of course. it’s not the best display of Clutter features — except the animation framework — but if you have hardware acceleration it will make slideshows look a lot nicer.

json-glib: this weekend I released the first developers snapshot of JSON-GLib 0.6; the API is stable, the test suite is rocking and this release finally fixes the last bit needed for full RFC 4627 compliance (Unicode escaping). I’m probably going to release 0.6.0 in a couple of weeks.

Good Intentions/2

gtk+: I’ve been working again on the RecentManager and in trunk you’ll see some new stuff, namely:

• use GIO to determine the MIME type of a URI, on every platform supported
• use the file monitoring API to avoid polling the storage file
• add a GtkSettings property for clamping the recently used resources list to a 30 days limit

more stuff I’d like to add is:

• small parser changes to GBookmarkFile, to reflect changes in the spec
• bulk addition, for applications storing multiple items when quitting
• new API needed to follow the usability review in bug 349541
• moving the RecentItem icon code to GIO, and add API to extract the thumbnail

twitter: I’ve been using Twitter a lot in the past two weeks; it’s nice, it makes it easier to copy and paste a quote or a thought, and the 160 characters limit is an interesting challenge. As it’s been ages since I last wrote an application¹, I decided to start writing a Twitter reader/writer — using GTK+, Clutter and Tidy; without much thinking, I opened gvim and started writing code in C² — so, the obvious thing that happened was that I ended up writing a library yet again in order to use Twitter’s web API. luckily for me, libsoup has now a really nice API to work with; all you need is GET and POST to their RESTful API, retrieve the result, parse it through JSON-GLib, hide everything inside a new GObject and you have a wrapper around a web service. the application, you say? oh, I was sure I forgot something. well, it’s coming along — it just needs some work still.

1. lately all I’ve been doing was writing libraries [↩]
2. hey, that’s what I do for a living, it’s hard to switch off; plus, I could reuse some of the platform libraries [↩]

Being Luis Villa

iain’s right: this is funnier than the history meme.

Good Intentions

unique: this morning I released version 0.9.4 of libunique, everyone (least) favourite library for writing single instance applications. it’s mostly a bug fixing release, and since I’ve decided to release 1.0.0 soon, this is also the first release candidate for the 1.0 milestone. I’ve also moved the git repository to github, so you can clone it with:

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

I plan to add back a new x11 backend for the 1.2 release, targeting small embedded environments were D-Bus might not be an option, and support for a --replace command line switch. after that, I’ll try to get the same functionalities into GLib/GTK+, as part of the future “desktop platform” module.

Clutter: I did a 0.6.2 release of both the core and the Python bindings, but things are afoot in trunk. we recently landed the multi-stage branch, which means that you’ll be able to create multiple windows and multiple GtkClutterEmbed widgets per application with Clutter 0.8. we’re also about to land the massive COGL rewrite that Ivan Leben of ShivaVG fame did — which will make the GL and GLES abstraction more powerful, will reduce the code duplication and in general will rock your world. Neil Roberts has been doing loads of work on the native Win32 backend: he not only made it possible to run Clutter on WGL, but also use the GtkClutterEmbed on Windows natively:

now, only the Quartz backend is missing the party — hint hint, nudge nudge.

OpenedHand: we’re hiring!

Rhyme the rhyme well

Jason, it’s not just the canvas: writing a simple 2D canvas is trivial — that’s why a lot of applications end up writing their own homegrown one.

The hard bits are the animation framework, the event handling and down to the integration with the existing platform. A generic canvas is hard, and you probably don’t want it to be developed inside gtk+ (not even for 3.0) — just like Cairo is not developed inside gtk+ but supersedes part of gtk+’s API.

As for 3D acceleration — I’m obviously biased here, so everyone should take what I write with a graintruckload of salt — but I maintain my view that if GNOME (and Linux) started heavily pushing towards more support for OpenGL, then we could get more market share¹, more visibility and thus more leverage to make the currently closed source drivers more open. Intel understood this; AMD is now getting it; I’m pretty sure nVidia will — or they will be simply pushed into irrelevance by the open drivers developed by the community². Let’s face it: other platforms and toolkits are pushing heavily on hardware accelerated 3D effects.

Let’s start aggressively work to get the platform into the XXI century.

update@2008-10-11T12:21+0100 — just as a sidenote: if you have a good CPU, Mesa and software rendering, Clutter will work. It won’t be fast for some operations (like scaling and, possibly, rotating), but in that case you should probably start contributing to Mesa to make it fast (there’s a lot of room for improvement).

1. think Compiz, and how many more users it brought home just with a spinning cube [↩]
2. unless you are a gamer, and need the very best card as soon as it’s out just to play Crisis [↩]

Time to Build

Claudio did some interesting profiling (and patching) of the BookmarkFile implementation in GLib — so kudos to him and Felix.

one thing that he noted is:

However, I still have the feeling that letting ~\.recently-used.xbel grow without control is very, very wrong. In my laptop, this file is about 5MB, which accounts for ca. 9000 files(!).

this is very true, but I feel it needs some context. when I first wrote the RecentManager code I only had the EggRecent implementation as a comparison; the old EggRecentModel had an hardcoded limit of 500 items stored per file. limiting on the number, instead of the age of an item inside a recently used file list did not feel right, so I thought about hardcoding a limit of 30 days — but stopped short of doing it because I realized that hardcoding limits at the toolkit level was not a good idea:

• application developers will not be able to change it in any way
• users will not be able to change it in any way
• system administrators will not be able to change it in any way

just to give a few examples: while I was still writing the RecentManager inside libegg, Alex Graveley was writing Gimmie. Gimmie had¹ a local document and application history that could allow you to go back in time of months; had I hardcoded a limit, the Gimmie developers would have needed a new implementation, defeating the purpose of shipping the RecentManager inside GTK+ to cut down the amount of code replication.

hardcoding limits is also something that makes it hard, or even impossible, for users and administrators to control; I might want a 30 days limit, but other might want a 90 days, or a 7 days — or even a 1 day limit. some might not even want to save the recently used files at all (think kiosks).

I don’t believe in strictly hardcoding policies in the toolkit; providing fallbacks is perfectly fine, but preventing people from actually having different settings is akin to convince everyone that you’re right and they’re wrong.

still, this doesn’t solve the problem at hand, that is the current lack of policy.

what I’d like to see is some process taking care of purging the old entries, using some key inside gconf, at the end of the session; gnome-settings-daemon would fit the role for GNOME, and other desktop environments using GTK+ could provide the same functionality². after all, gnome-settings-daemon should already flush the thumbnails cache — it wouldn’t be much of a complication.

1. and might still have — I haven’t checked it for a while now [↩]
2. if you’re not using a GTK+ based desktop environment you’re either using the same spec used by GTK+ so you can provide your own way of purging the cache, or you’re using another way to store the recently used files, so the size of the file saved/read by the RecentManager will not bubble out of control so easily — and you can still flush it yourself [↩]

Berlin/5

last post of the Berlin Hackfest series, written on the last minutes of day 5

today was “wrap up” day. we got together in the room used for the presentations and summed up all our work during the various sessions of the week. it turned out that the amount of work, even though not reflected by the wiki page, was really enormous; the introspection guys worked a lot and now that they have received a lot of input, they are going to rework things and kick ass even more. apparently, Behdad decided that I would tackle the GL integration inside GDK — which, of course, I’d really like to do; the GL integration, and a GDK wrapper for the GLX_texture_from_pixmap (and the equivalent call for the other platforms) would obviously be the primary way to integrate Cairo 2D high quality drawing and GL 3D and hardware acceleration in a simple way. and this is a step forward the implementation of a scene graph inside GTK+.

in the meantime, I’m — as Ryan would put it — deeply recursing. it all started on tuesday, when I decided to start hacking on a real application with Vala using all the bits and pieces a modern GTK+ application requires: GtkUIManager, about dialogs, command-line switches. the application was supposedly going to read the new GTest framework reports, and allow comparing of multiple runs in a fast way. this, in turn, led to some bugs filed against Vala GTK+ bindings. working around these issues, I also found out that the libxml-2.0 bindings in Vala — which I need to parse the GTest report XML — require a lot of pointers usage and are, in general, quite sub-obtimal, due to the very C oriented API. while investigating on a substitute, I found out XmlReader — the cursor-based XML traversal API that .Net and other high-level languages implement¹. Thus, today at a coffe shop² I started hacking very quickly on a rough implementation of a XmlReader GObject class which, as of at this moment works quite nicely:

  XmlReader *reader = xml_reader_new ();
  GError *error = NULL;

  if (xml_reader_load_from_file (reader, “book.xml”, &error))
    g_error (“Unable to parse book.xml: %s“, error->message);

  xml_reader_read_start_element (reader, “book-info”);

  xml_reader_read_start_element (reader, “author”);
  author = g_strdup (xml_reader_get_element_value (reader));
  xml_reader_read_end_element (reader);

  xml_reader_read_start_element (reader, “title”);
  title = g_strdup (xml_reader_get_element_value (reader));
  xml_reader_read_end_element (reader);

  xml_reader_read_end_element (reader);

  g_print (“The author of %s is %s\n“, title, author);

  g_free (title);
  g_free (author);
  g_object_unref (reader);

and you’re done. at this moment, I’m cleaning it up and adding the gtk-doc API reference to the build³. I’m probably going to add the generic read() method, so that:

  while (xml_reader_read (reader))
    {
    …
    }

will work as expected. it’s, as usual, code replication — but I’m going to need it anyway, so it’s good code replication.

1. Even libxml-2.0 implements it, even though it suffers from the same issues of its DOM API, and it’s still not GObject-based [↩]
2. Behdad is right: a coffee shop without any Internet connectivity makes wonders with your productivity levels [↩]
3. When I write new libraries, I usually stub out the API and document it at the same time; now I started to add the GTest units before I even implement the API [↩]

Berlin/3

second and third day of the hackfest, edited on day five

on tuesday, Behdad and I started working on OpenGL integration inside GTK+. as stated multiple times on the Bugzilla entry, what we both would like is a Cairo-like integration of GL inside the available drawing systems in GTK+. in short: not a specialized widget like GtkGLArea, which would make it difficult — or plainly impossible without jumping through a long series of hoops. in flames. tied. and blindfolded — to integrate GL inside existsing projects; and not the incredible API dump that GtkGLExt is.

the design we mostly agreed on was a shared object inside GTK+, containing the GL context abstraction object, and two simple calls to delimit the drawing code, wait for vblank and swap the GL buffers. plus, an easy to use wrapper around the texture_from_pixmap extension, to allow drawing with cairo on a Pixmap and then have it pushed into the GL pipeline.

Carl arrived on wednesday, and partecipated at the scene graph BoF we held. the BoF itself was pretty straightforward: we read the slides that Havoc sent on the mailing list and discussed the various points. we all agreed on a lot of points — and we tried to define the problem space more deeply¹. being there, I could bring to the table my experience in the past two years² with the design and implementation of Clutter. some of the attendees were already familiar with it — something very satisfying — and I could expand some points in Havoc’s slides about Clutter that have been recently fixed or are going to be fixed in this cycle. the biggest point is that the scene graph should integrate with Cairo, in order to allow applications and people to gently merge both the 2D drawing of surfaces into a full 3D environment; I’ll leave to Carl to explain the Cairo side, because he’s obviously better at this than I am.

the operative result of the scene graph discussion was that Clutter emerged as an already powerful and established solution for this problem space, and given that it already nicely integrates with GTK+, we can work towards the common goal of making it “the GTK+ canvas”, outside the actual library so that it can grow unrestrained and experiment in new directions.

1. We did not always succeed in this, but the issue at hand is quite large and it’s understandable [↩]
2. It’s really two years? holy crap! The time really flew… [↩]

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 beta¹ 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 [↩]

Helm, set a course… for love

a GNOME cruise? I already have the theme song…

GNOME-Love Boat, love exciting and new,
Come aboard, we're expecting you.

The GNOME-Love Boat soon will be making another release,
The GNOME-Love Boat promises something for everyone.

Set a course for adventure,
Your box's on a new romance.

And GNOME-Love
Won't hurt anymore,
It's an open source,
On a userfriendly shore.

it's GNOME-Love
Welcome aboard it's GNOME-love

Paint the Silence/2

Continuing the ongoing saga…

Using the --silence hackery from Jacob Berkman I found a way to finally STFU at least libtool. In your configure.ac add:

changequote(,)dnl
LIBTOOL=“\$(QUIET_LT)${LIBTOOL}”
changequote([,])dnl

Add a Makefile.decls file to the root of your project, containing:

QUIET_LT = @echo ‘    ’ LIBTOOL $@;

And include it in every Makefile.am:

include $(top_srcdir)/Makefile.decls

This will silence all libtool invocations; you can make this all conditional, obviously: just sorround the QUIET_* declarations with if VARIABLE...endif and define VARIABLE using AM_CONDITIONAL in your configure template.

Now, I’ll just have to find a way to make gcc shut up¹, and so the saga will end with a third chapter.

1. no, you cannot redefine CC, as it will be invoked by libtool as well [↩]

Rag And Bone

Usually, when writing bindings for a C library in a high level language, there’s a sweet spot where you have to leave the relative safety of an API similar to the library you are wrapping and the idiomatic correctness dictated by the language itself.

For instance, in the PyClutter bindings a typical clutter.Behaviour constructor is lifted directly from the equivalend function call:

  behaviour = clutter.BehaviourDepth(alpha, -100, 100)

  behaviour = clutter_behaviour_depth_new (alpha, -100, 100);

The ClutterAlpha parameter, though, can ben NULL, so a “keep the API similar to the C equivalent” approach would be:

  behaviour = clutter.BehaviourDepth(None, -100, 100)

  behaviour = clutter_behaviour_depth_new (NULL, -100, 100);

This is, though, different from the “pythonic” approach; as Python has the syntactic sugar to support arguments with default values, the place for those parameters would be at the end of the function call:

  behaviour = clutter.BehaviourDepth(-100, 100)

Correctness issue aside, let’s add the fact that a pythonic approach allows the poor maintainer (yours truly) to drop a lot of hand-written code.

Unfortunately, though, the pythonic approach breaks the API¹; more unfortunately, it breaks the API without giving a useful error message: the PyGObject bindings will raise a not very useful

  "TypeError: could not convert parameter 'depth_start' of type 'gint'"

exception when encountering the wrong value type for the argument².

The question then is: should the idiomatic correctness sway in favour of the language or the underlying library?

Here the blog post ends. I’d like to have an answer for the question, but I’m still undecided; if anyone has some insight, especially Python developers, I’d appreciate a comment

1. This is not a huge issue as it might seem: the underlying C library has already done that for us [↩]
2. The error message should be a more useful “could not convert value of type X, and parameter Y requires a value of type Z”, which would require a bit of tinkering in the bindings themselves and it wouldn’t be useful anyway because only the new versions would pick that change up [↩]

Paint the Silence

Weee, long time, no blog.

Dear Lazyweb,

is it at all possible to coerce the devilspawn also known as libtool to actually be quiet when compiling and printing something like the kernel compilation outpout - that is, something like:

  GEN autogenerated.c
  CC file1.c
  CC file2.c
  LINK output
  INSTALL output

I know how to do that with a plain Makefile, and how to do it for autogenerated files like the enumeration types and the GLib marshallers, but I have no clue where to start to make libtool behave.

Thanks,
Emmanuele

Stinging Velvet

Clutter - If release 0.4 rocked hard, release 0.6 of Clutter will blow your mind away. Just to list some features landed in the past couple of weeks after ClutterScript got in:

• new event handling, borrowing from the W3C DOM event - that is, two event phases: capture, which traverses the scene from the stage to the actor that received the event, and bubble which traverses the scene from the actor to the stage. You can block the event chain in any point of both phases by simply returning TRUE in the signal handlers (like GTK+); kudos to mallum and Pippin
• improved text scaling, at least for downscaling at ~50%; kudos to Pippin
• build and test on win32 using the SDL backend, complete with VS2005 build files; kudos to tf
• time-based timelines, so you can define a ClutterTimeline by giving its length in milliseconds; and without even breaking the API.

Still, there’s plenty more coming - so keep looking at trunk.

JSON-GLib - The code base has been consolidated a lot while working on ClutterScript, so I feel confident about making a release of the out-of-tree repository. The release is bagged, tagged and signed as json-glib-0.2.1 in the git repository¹. You can grab the tarball here. Work on seamless GObject-JSON (de)serialization will continue in the master branch towards a 0.4.0 release. Update@2007-10-16T23:30+0100: obviously, as soon as I got back home and checked the repository I found two bugs in the generator code; hence, brown paper bag release 0.2.1. Tarball, documentation and tag updated.

1. As usual, at http://folks.o-hand.com/~ebassi/git/json-glib.git [↩]

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 read¹. 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.net¹. 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 git², 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 scripting³. 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 [↩]

My Wandering Days Are Over

This weekend I’ve finally tried Vala, something I wanted to do for a while now. Vala is, for those of you that never tried it, like GOB, but on PCP and steroids and with a syntax that doesn’t make using it feel like you’re being skull-raped through your eye sockets. It’s, actually, quite a pleasant experience - if you ignore the utter brain damage of connecting signals by overloading the plus operator¹.

Surely, there are a couple of issues with the underlying C translation layer:

• connecting signals passes the class instance pointer, but if your class does not have any property then an empty struct will be generated, which doesn’t create valid C code;
• if you then add a dummy int, the passed pointer is still called “self” but it’s never allocated, because the Vala compiler still expects for the class to inherit from GLib.Object in this case, while it really shouldn’t;
• so, if you want to connect to signals, you have to make your class inherit from Object, create an instance and connect to the signals in the constructor or inside a method;

The last point is a perfectly legitimate choice to be made by language designers: but, then, this snippet:

using GLib;
using Gdict;

class TestSource {
  void on_definition_found (Gdict.Context context, Gdict.Definition definition) {
    stdout.printf ("*definition for `%s' found:n%sn",
                   definition.get_word(),
                   definition.get_text());
  }
  static void main (string[] args) {
    var loop = new GLib.MainLoop (null, false);
    var context = new Gdict.ClientContext ("dict.org", 2628);

    context.definition_found += on_definition_found;
    try {
      context.define_word ("*", "dictionary");
   } catch (Glib.Error e) { warning (e.message); }

    loop.run ();
  }
}

should fail to compile in Vala, and not in produce invalid C code².

Anyway, Vala is an interesting project. If it had a better integration with the rest of the toolchain (gdb, valgrind, autotools, profilers, etc.) it should definitely become one of the first class citizens of GNOME³.

By the way, just to try out Vala I wrote the bindings for the Gdict API. They are mostly working, so if you want to check them out, you can clone the repository here:

  git clone http://www.gnome.org/~ebassi/git/gdict-vala.git

Those are the bindings for the unstable version of Gdict, which will be released for GNOME 2.20.

1. which is more a fault of C# than anything, and one of the reasons operator overloading should be banished using necromancy. Come on: signal = signal + handler? Really? [↩]
2. I think this stems from the fact that Vala, like C#, allows a mixed OO-procedural approach, like Perl and Python; but those languages usually get it right [↩]
3. for instance, Apple has native Objective-C support, and that is a layer above C like Vala [↩]

Flying Teapot

Clutter 0.4.0 was, finally, released two days ago. Not only the core and add-on libraries but also the language bindings are available for this new stable release cycle.

We already started working on trunk for the 0.5/0.6 development cycle, which should hopefully lead up to another stable release in six months; there already is a nice list of features we are working on, but I’d like to see more requests, more patches ( ) and people working on even more language bindings.

GUADEC/recap

This year’s GUADEC has been really great - it seemed hard to top last year’s but paul, thos, robster and the rest of the GUADEC team really rocked hard to make everything work at its best. Kudos to all of them.

Unfortunately, my GUADEC was cut short on Wednesday for a small medical emergency, as my wife had some health problems on Tuesday night that got worse on Wednesday. Now it seems everything’s back to normal, but as we’re still expecting some of the lab analysis to come through, we had to postpone our holidays and the trip back to Italy.

I could only stay in Birmingham for the GTK+ “state of the union” (awesome) talk by Kris and the 3.x4.x workshop and see the wonderful presentation Fer and Xan did - really funny but also straight to the point. The following discussion was a bit hijacked towards the ABI/API break issue, which I believe is neither interesting nor really important. I also missed the Clutter talk on Thursday, but I was told Matthew rocked. It’s fun to see people picking up Clutter and finding it API-friendly: it’s hard, being very near to it, to judge whether some of the choices you make are the right ones.

I had to cancel my tutorial on Perl and GTK+, as well as the GConf workshop. I’m very sorry if this has caused you some trouble; I heard that Ryan did an interesting talk on his dconf project, though.

I missed Havoc’s keynote on the online desktop, but went to Alex’s keynote; it was intriguing, even though I disagree on some of his points - especially the bit about Firefox being an interesting platform to develop towards or with, after the utter disregard that the Mozilla developers have had in the past for Linux and GTK+ (two issues spring to mind: borked clipboard usage and UTF-8 drag and drop); oh, and I don’t think I’ve ever seen the words “good engineering practises” and “small extensible core” anywhere near “mozilla”, unless “the Fox” that Alex mentioned was a new web browser I’ve yet to see. What I completely agree is that we need to tap into the resources of the non-C, non-hardcore programmers: we need tools to make possible for Flash developers, for Javascript developers, for designers to use our platform, and provide new ideas; in short, make the platform interesting and usable for developers, like the desktop should be interesting and usable for the users.

Let’s take Plasma, the new environment KDE provides for writing their version of desktlets-dash-widgets-dash-applets-dash-somethingets. Obviously, right now, it’s just an exciting new way to write not really useful stuff, like the uptenth variant of a clock, or a weather applet, or a note taking applet; but you get an HTML canvas widget, and you can write ${FOO}ets in Javascript. This way, KDE will get a truckload of useless stuff lying on a desktop which will be covered in windows anyway - but they will also get the attention of web developers writing small apps integrating with web services in a transparent way, using their own strengths and knowledge, without forcing them to learn the intricacies of a complete platform; and in time they’ll get those developers to know this platform and gain new workforce to work with it, and on it. Compare to GNOME: if I want to write something as simple as a desklet, right now, I’d need to know GTK+, Cairo, GConf and possibly gnome-vfs, libsoup, or third party modules for talking to web services through their API. The curve for contributing to the platform is still too steep; and you don’t even get to use your own knowledges: you have to learn everything from scratch. KDE core developers understood this before we did, and their move might keep KDE from falling into the irrelevancy of geek-only usage. It’s up to us find a way for making the GNOME platform interesting again for developers, as well as users.

Take it or leave it

After the comments on my latest blog post, I got back at Unique and did some rearrangements in the code base. Now the backends are all compiled in (obviously, depending on whether you have the dependencies to compile them) and the backend to be used can be defined at runtime. The default backend is chosen at compile time and can be overridden by setting the UNIQUE_BACKEND environment variable. Obviously, if you launch an instance with UNIQUE_BACKEND=dbus and another one with UNIQUE_BACKEND=bacon you will have two instances running - but that’s only to be expected.

I’ve also updated the API to something I can probably call “semi-frozen” (small API additions notwithstanding); the constructor changed to always accept a startup notification id (it will try to be clever and find it for you if you pass NULL, though) and allows you to define custom commands with a single call.

As usual, you can clone the Git repository from here:

  git clone http://www.gnome.org/~ebassi/git/unique.git

or grab the tarball for 0.9.20.9.3 from here.

I’ll keep working on making a 1.0.0 release at GUADEC (probably it’ll happen right at GUADEC), API/ABI stable and with the Xlibs backend. Then I’ll resume working on the GtkApplication class, which will have the Unique features but will (hopefully) be integrated in GTK+.

Update@2007-07-12T12:54+0100: New release, with full API reference documentation, a couple of stupid bugs squashed and workspace support.