Month: May 2016

Vala programing language is, let say, misunderstood most of the time. May this explain, why there are few support for IDEs, like GNOME Builder, at least at beginning.

In 3.20.4, GNOME Builder has improved and stabilized its support for Vala development, proven to be stable enough for daily usage. Even I started to use it for GXml upstream development. But it was a little difficult, because I want to stay in a stable long term supported OS, like Debian 8.

Debian 8, has been discarded by GNOME wiki, to install and develop using jhbuild, making hard for me to develop upstream. In order to solve this, I started to test Builder from xdg-app and nightly builds, because, it suppose to be in sync with master (upstream) versions of basic Platform, for upcoming 3.22. While I rather happy with Builder running this way, you need some extra configuration to develop any Vala project under xdg-app sanboxed environment.

While Vala 0.32 is available in org.gnome.Sdk 3.20, the one I’m using to develop GXml, no libgee is installed and you can’t simple compile and install it, because in the Builder sanboxed environment, /usr is mounted read-only. So I first:

1. Get libgee sources
2. Set “Installation Prefix” to /home/yourusername/.local
3. Disable instrospection (–disable-introspection), by setting “Configure Options”
4. Use “Host operating system”

This will make the trick to compile and install libgee in your home directory. Libgee doesn’t requires other dependencies. But for GXml, we need a few more work, because you should setup it to find pc files for libgee and more important, to find its VAPI file.

To configure GXml on Builder, in sanboxed environment:

1. Get sources
2. Set “Installation Prefix” to /home/yourusername/.local
3. Disable instrospection (–disable-introspection), by setting “Configure Options”
4. Use “Host operating system”
5. Set “Environment” variables for VALAFLAGS and PKG_CONFIG_PATH
6. In your Makefile.am make sure you add –vapidir=/home/yourusername/.local/share/vala-0.32/vapi to your Vala compile flags.

VALAFLAGS is useful for code completion in Builder, add most of your project Vala flags. PKG_CONFIG_PATH should be set to /home/yourusername/.local/lib/pkgconfig in order to find pc files of your locally installed dependencies.

You’ll find Builder complaint by reporting some warnings, most of them coming from libgee usage.

Building your Vala project in Builder, is no jet really integrated, because most errors are shown in terminal “Build Output”, but not in build messages, no other than the libgee ones. Fortunately, you have color output from valac, making more easy to find errors and warnings.

Most of you may will use a distribution, to use Builder and jhbuild, making easy to develop upstream. I can’t do that, because some other activities requires me to have an stable system, avoid interruptions because my unpaid contributions to GNOME.

Using W3C specifications for DOM 4, I’ve managed to copy & paste its interfaces, then with few adoptions are now GObject interfaces thanks to Vala.

Now I’m implementing them using GNode classes, this is in order to deprecate xNode classes, while we provide a more modern API.

The progress are so straightforward, at least for now, with few code. I’ll try to avoid any API break this time, unless it is impossible to implement DOM4 API.

While actual API is powerful enough to do most DOM4, there are missing or just useful API we can take advantage of.

For example, DOM4 provides events API, witch we can implement provide using GObject signals, but even so I’ll try to do my best to keep the DOM’s one.

I will implement step by step each interfaces functionality, on existing classes; may I leave events for a second try. I need to implement all basic interfaces, before I can push to repository.

Even so, all API interfaces are in place, and may will suffer some Vala adaptions, but not too much. If I can’t implement them I’ll hide them from public API, until they are implemented.

While GXml has C API, it is written in Vala, then this posts will show you how to use GXml’s Vala API to get GObject to XML and back easy.

Lets start with a simple class and GXml’s implementation of GXml.Serializable, called GXml.SerializableObjectModel:

using GXml;

public class Record : GXml.SerializableObjectModel {
  public string name { get; set; }

  // GXml.SerializableObjectModel overrides
  public override string node_name () { return "Record"; }
  public override string to_string () { return @"Record: $name"; }
}

The above example, defines a class called Record witch should be written in XML as:

<Record name="Daniel"/>

This just happen if Record.name is set, if no you’ll get:

<Record/>

In order to get this XML to be written you’ll need:

var r = new Record ();
r.name = "Daniel";
var d = new GDocument ();
r.serialize (d);
stdout.printf (@"$d");

The above code will print an XML representation of your object, with the given values, as shown above.

If you have an XML file or string, you can use following to read data from:

var r = new Record ();
var d = new GDocument.from_string ("<Record name=\"Jhon\"/>");
r.deserialize (d);
stdout.printf (@"$r");

The above code will print your object string representation using Record.to_string().

GXml.SerializableObjectModel will inspect all your public properties, trying to print out string representation of each. Most basic types are sopported, while you can override default GXml.SerializableObjectModel.serialize_property() in order to catch up when an special property like GLib.List is corrently serialize to create your custom serialization; if you do so, remember to override GXml.SerializableObjectModel.deserialize_property() to get back string to your property. Remember, GXml.SerializableObjectModel is just an implementation of GXml.Serializable interface and you can both, override default methods or implement your own.

Next time we can review how a set of XML tags could be de/serialized from XML using builtin GXml serializable collections.

GXml is a library, written in Vala, providing a good support to read and write XML files. Behind it you’ll find libxml2, wrapped by GObject classes.

Initially written by Richard Schwarting, to provide DOM Level 3 support on libxml2, now it has a set of interfaces, making easy to write different backends. While today just libxm2 is used, GXml have three GObject classes, one in with the original DOM support, one optimized to gain better use of libmxl2 and one in pure GObject. All of them allows you to access XML objects, like tags and properties, navigate over XML tree and modify if you need it. Each implementation of general purpose interfaces, like GXml.Node, have its own advantanges: DOM support, low memory foot print or better performance with larger foot print. Is a matter of you on what implementation you need.

My motivation on GXml, was initially pushed to have a low C library to support reading Substation Configuration Language files, IEC 61850-6 standard XML based files to energy related devices configuration. This files are large and complex. While there are a free open source project to handle them by LibreSCL, in order to have it working, GXml should gain GObject to XML serialization/deserialization. This has lead to commercial products, running both on Linux and Windows.

I’ll write down about how GXml serialization can be used for GObject Serialization, wait second posts.

GNOME Data Access (GDA), is a C library for Database access, it provides a library to write clients and a set GTK+ widgets to help write GUI applications; it also provides a control center, a SQL browser and CLI a la PostgreSQL’s psql command.

It is really useful, but could be better if most of its advanced futures are available for GObject Introspection (GI). While GDA has support for GI for a while, there are some structures in C and some API witch has been marked as no-introspectable, automatically or hard coded.

Making a C library introspectable is a little easy, but requires a lot of work, by hiding structs members and provide getters and setters methods for its members (sealing); make sure you are handling correctly struct’s memory management, freeing on request, but most importantly, is to convert this struct as a GBoxed type, making easy for bindings to create, read/write members (using its setter/getter), free, copy  and pack it to a GValue.

The hard work on making a struct introspectable, is to substituted all direct access to its members to use its new API. This is a hard work as you can see when GdaBinary was sealed to make it introspectable.

You can follow GDA Instrospectable bug and its bug dependencies, in order to know how has been solved each case; may that will help you to create better C introspectable API or help us in the process.