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.
Thanks for these write ups Emanuelle, they are really appreciated by those of us that couldn’t make it.
And this is really great news!
/Micke
It would be easy to make GObjects for most of the libxml API (DomParser, SaxParse, XmlReader, DtdParser, etc, plus Elements, Nodes, Attributes, etc). Someone would just have to translate libxml++ to GObject. We’ve already figured out the weird stuff for you:
http://libxmlplusplus.sourceforge.net/
But most C coders will continue to tolerate the libxml API, I guess.