Berlin/Final

some final thoughts on the Hackfest: it has been a great opportunity for discussing with all the usual suspects and more, and on a very high bandwidth channel — unlike IRC or the mailing list. definitely, an experience that must be repeated next year, because the discussions we had and the work we started will keep us all busy at least until GUADEC — and from then on, towards a very bright future for GTK+ and the whole GNOME project.

thanks to Mathias and Openismus for being the local organization; thanks to Tim, Kris and the entire Imendio, for moderating the whole panels; thanks to Vincent and the GNOME Foundation, and obviously all the sponsors, for helping out in organizing and funding this gathering of hackers; and thanks to everyone that made these five days an incredible experience for me: you all really rock the GNOME community.

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 ((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)). Thus, today at a coffe shop ((Behdad is right: a coffee shop without any Internet connectivity makes wonders with your productivity levels)) 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 ((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)). 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.

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 ((We did not always succeed in this, but the issue at hand is quite large and it’s understandable)). being there, I could bring to the table my experience in the past two years ((It’s really two years? holy crap! The time really flew…)) 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.

Berlin/1

day two of the gtk+ hackfest.

yesterday was devoted to the Imendio vision of a better toolkit, and how to get out of the hole we dug for ourselves with the current API/ABI contract – but others have written about it better than I could possibly do.

today was introspection day; Johan Dahlin showed the current state of the GObject introspection code by using a Vala widget, subclassing a GtkDrawingArea, from a Perl script — which was beyond cool. kudos to everyone that has been working on it.

today it’s also six years since the gtk+ 2.0.0 release, so happy birthday gtk+ 2.x!