Modify SVG using GSVGtk: First Report

GSVGtk is a library to provide GTK+ widgets you can use to access SVG files. It is powered by GSVG, in a way it can access each shape and its properties using a GObject API based on W3C SVG 1.1 specification.

Currently, GSVGtk uses Clutter to encapsulate SVG shapes, render them inside Clutter Actors, through librsvg, and maps events to source SVG in order to eventually modify original definitions, like its position.

In the following video, you can see GSVGtk’s Container based on Clutter, loading an SVG file, take some shapes from it to show on the scene.

Shapes can be moved around, with feedback about its position in millimeters. If it is moved out of the stage, you can pan the scene to reach it.

GSVG allows to add SVG transformations to shapes, like scale and translate; matrix, skew and rotate are a work in progress. Once finished, they can be used with Clutter Actors to render transformations on screen with GSVGtk.

All CSS properties required in the standard are present in GSVG, but a good UI to modify them is required, may some of you want to create mockups to be implemented.

GTk4 and GSVGtk

On GTK+’s IRC, I asked for GTK4 and the future of Clutter, I get some recommendations from GTK+ developers. I’ll keep Clutter for backward compatibility and to able to use GSVGtk in LTS distributions, but add interfaces, a la GDK, to be able to have different backends.

Clutter based backend will be the first to be finished; next or in parallel, I’ll port GSVGtk to GTK4, in order to eventually drop Clutter support when GTK+ 4.0 reach long term stability, around 4.6 release.

GSVGtk and PLogic

PLogic will be the first project to take advantage on GSVGtk and GSVG, in order to render logic diagrams, with basic edition capabilities.

All basic edition capabilities required for PLogic, will push ahead GSVG development to implement new features from specification, as long as GSVGtk to provide graphical tools to archive them.

SVG Rendering

GSVGtk, no GSVG, uses librsvg to render SVG shapes and text on screen. librsvg is fast, but for large projects I think the pipeline used currently will find a bottle neck.

For rendering, GSVGtk ask GSVG to generate string representation of SVG  in XML, then pass it to librsvg for rendering. This can be avoided if librsvg exposes internal rendering methods in order to call them directly using GSVG structures and objects.

A solution is to take a dive into librsvg source code, extract that methods, import to GSVG or GSVGtk (thanks free software), so rendering can get a speed up. Yes create MR for librsvg to expose them is an option, but I need C methods and maybe this is not in line with the progress of Rustify work in librsvg.

Rendering directly, will help to avoid rendering to Clutter Canvas, which imposes semi-transparent backgrounds for shapes, see the video. More importantly, a direct rendering, will help on shapes selection  as their sensitive area can follow its own form to avoid square areas and allow to select objects behind other with transparent fill out.

Again GTk4 will be a very interesting thing to checkout for SVG rendering, may it will expose a good API, a la Cairo or similar, to help implement or port librsvg methods on. No sure, because no time to check that API now.

GXml is near for ABI stability

Today I managed to create a patch to provide ABI stability for GXml and any other Vala library.

ABI is one of the more important aspect in a library; allows to produce binaries fixing issues and add features while the applications, depending on it, don’t need to be recompiled

Vala libraries need to add annotations in order to produce binaries interoperable with applications linked against an old version, Gee is the best example.

Now with the refered work, you can easily manage ABI without worrying about annotations, just take care on the order your virtual/abstract methods and properties are declared in your source code, in order to preserve your library’s ABI.

ABI stability for GXml

I’m taking a deep travel across Vala code; trying to figure out how things work. With my resent work on abstract methods for compact classes, may I have an idea on how to provide ABI stability to GXml.

GXml have lot of interfaces for DOM4, implemented in classes, like Gom* series. But they are a lot, so go for each and add annotations, like Gee did, to improve ABI, is a hard work.

I think is better to improve Vala code to produce ABI stability from the beginning; this will help GXml, GSVG (implementing W3C SVG 1.1 interfaces) and GSVGtk, to have abstract classes and interfaces with good ABI stability without change a line of code in them.

In the process, we can have reproducible API, that is: same C header from compilation to compilation of Vala code and when you add new API. Of course, this means that you should follow basic rules when write Vala code, but no more than the ones on the C side, well may be a few ones. When this is in place, you may add your library header to your repository to track changes to it; once a new API has been added, you should be able to take care about ABI and API, to make sure they are consistent over time.


Productive language for GObject, GType and non-GType based software.

GXml 0.16.0 Released

GXml is a library for XML access and GObject serialization to XML, with a W3C DOM4 API implementation.

Many bug fixes for XML access, serialization improvements and initial CSS selectors through DOM4 API,

GXml provides a powerful serialization frameworks, with different implementations, to provide flexible, fast and reduced foot print applications. Use GXml to access your XML documents using a GObject API, and thanks to Vala, your libraries can be used from C, Python, JavaScript and any other language with support for GObject Introspection.

Thanks to GXml’s Object Model (Gom) implementation, your GObject classes are XML nodes, with support for child nodes and dynamic properties and name spaces, with a great flexibility to read XML files in a format-free form, so your classes will be able to access past and future versions of XML files.

GXml is the motor for different projects, including SVG and Station Configuration Language,  allowing fast GObject API implementation based on specifications, like the one forW3C’s SVG 1.1, and XSD definitions.

This release arrives with a record of all bugs reports fixed. While may this is not good, because more users means more applications and more bugs, so having this number, should be considered just the beginning of a new cycle.

Next development cycle will be focused on API/ABI stability, add more CSS selectors implementations and improved performance for large set of XML nodes.

Many thanks for all contributors, bug reporters and translators.

Vala Warnings output Improvements

As for resent release of Vala 0.39.4, there are huge improvements if we talk about warnings output at Vala code and C code compilation level.

One of the argument against Vala, has been the number of warnings you get for a valid Vala code at C level compilation. As an example you can check warnings for GXml in March 2017 about 230, some were my fault but other at C level.

Resent rebuilt in January 2018 for GXml shows a drop to just 9 warnings. But the extraordinary thing is that no C level warnings at all! Remaining warnings are for missing features in GIR format and one from Vala code.

Hope to find time to publish resent Vala improvements this 0.40 development cycle.

Vala’s Abstract Compact Classes

From this bug, reports a bug on using abstract compact classes with abstract methods. This is perfectly usable in GObject derived classes or GType based, but no for compact classes, they are not any of above.

Because is possible to add pointers to a struct, as GObject does, I’ve managed to create a patch to add support for abstract methods in compact classes. They provide pre-defined implementations with warnings outputs, as for GType/GObject based classes, and is possible to override them in derived classes.

Compact classes are really cheap on resources and construction, you can create really useful and easy to use C API from them and can be introspectable if you define methods to access your struct members.

If you want a fully and friendly bindable C library written in Vala, I recommend you to use non-compact classes.

This should start to demystify an old argument that Vala is just for GNOME. Vala for for GObject and GType based applications, no matter it is targeting Linux, Windows or OSX. Its productivity is great and no other language, to day, have same level producing GObject/GType based applications without overhead.

GTK+ Custom Widgets: General Definitions

Writing a GTK+ custom widget with Vala is easy. First all create an XML definition with a top level container widget and a set of child ones. You can use Glade to do so. This is not a tutorial for Glade, so let start at with an already designed template UI file.

For this Glade UI file to be useful in this tutorial pay attention on:

  1. The top level widget’s type must be the same of the one your Vala class is derived from.
  2. The top level widget in your UI file must be declared as a template and should have the same ID as your class, this is the C name, a class called Cust.DateChooser, should be called CustDateChooser in order to allow Vala’s compiler to find its UI definition.
  3. The child widgets, to be controlled by your class should have an ID.

Take in account all these for following delivers.

Continue reading “GTK+ Custom Widgets: General Definitions”

Large number of XML Nodes and GXml performance

GXml performance has been improved since initial releases.

First implementation parse all to libxml2 tree and then to a GObject set of classes, in order to provide GObject Serialization framework.

Over time GXmlGom was added as a set of classes avoiding to use libxml2 tree improving both memory and performance on Serialization.

GXml has been used in many applications like parse Electrical Substation Configuration Language files by; to Mexican Tax Authority XML invoices format, among others.

QRSVG Performance

For my private projects, I need to create QR of size 61×61 = 3721 squares. This means at least 2700 XML nodes. This is a large number of nodes and because QRSVG depends on GSVG and it depends on GXml, all them depend on GXml’s implementation for performance.

Initial measurements suggest that, at no surprise, using a simple array of objects takes up to 0.5 seconds to add just a node, as maximum time measured.

So GXml’s implementation should be improved for large number of nodes. Now it uses Gee.ArrayList, is clean and easy to wrap a node list implementing W3C DOM4 API. But now I’m considering to use Gee.TreeMap, because it is designed for large collection of objects, from its documentation:

This implementation is especially well designed for large quantity of data. The (balanced) tree implementation insure that the set and get methods are in logarithmic complexity.

The problem is its Map interface, where I need to implement a Gee.BidirList interface over it, in order to ensure fit in W3C DOM4 API and get performance boost.

Lets see how evolves this. Any suggestion?

Vala Tip: Don’t add an already implemented interface to a derived class

While implementing GSVG, I had to add DomDocumentType to a DomDocument, so your renderer will recognize it is a SVG document, so I use following:

class GomNode : DomNode

class GomDocumentType : GomNode, DomNode

Note GomNode is implementing DomNode, so yo don’t need to add that interface in its derived classes GomDocumentType.

Hours after a set of debugs, I found you should don’t do that, because it produce a infinite cycle, leading to a crash.

So, your GomDocumentType should be:

class GomDocumentType : GomNode

Now GomDocumentType is a DomNode too.


At least for me, no SVG API is available as GObject API, so you have to deal with libxml2 library. On the other hand renderers are librsvg, but lacks API for SVG creation and Edition.

W3C has published an API specification version 1.1 for SVG and describes how renderers should interpret this XML document. W3C SVG depends on DOM as API to access XML documents.

While developing PLogic, I realized to have no way to create graphics for it, so take a look at GXml to dinamically generate SVG based on a logic diagram, using a GObject API to access XML documents. But no GObject API exists for SVG creation and edition.

Implement W3C API, is a matter to use OOP, like Java or C#, but a pain if you want to use pure C and GObject. So I choose Vala, because its syntaxis is very similar to W3C API and C#, making really easy to implement the API in a set of interfaces first and then in classes implementing those interfaces.

GXml lacks a good DOM support, due to liminations on libxml2 it relays on. So I started to implement a new pure GObject based set of classes, using libxml2 just for parsing and writting; they simple overcomes libxml2 limitations and now implements most DOM4,  whitout transformations.

GSVG now uses GXml’s GomNode classes series, improving time to implement features in W3C specifications.

GSVG have pushed GXml ahead, by exposing bugs and requesting new DOM4 implementations in order to provide useful SVG documents.