Maintainers behind Vala compiler, have been busy this cycle.

Vala has a continuous integration machinery, so new features are added to staging branch before to land in master, in order to check some Vala projects can be compiled and their unit tests pass.

Expect more Vala improvements, fixes and backports to 0.34 and 0.36, so you can use them in your favorite distribution.

While 0.34 haven’t been officially declared as a long term support branch, it has received most fixes and backports, so stable releases, like Debian upcoming Strech, can provide reliable, stable and improved experience to developers targeting GNOME 3.22/Gtk+ 3.22 stable releases.

Vala’s bindings using GIR format are updated constantly and because them can be generated automatically from project’s sources, new API additions/changes land in master really fast. Is the case of GTK+ 4.0 unstable; allowing you to create testing/prototypes using latest hot GTK+’s new features, using Vala.

Highlights:

• gobject-2.0: Add GLib.ParamSpecPointer
• The CCode attribute ‘cname’ needs to be the canonical representation as it is expected in C. [Bug 731547]
• gio-2.0: Use default ‘length = null’ for DataInputStream.read_line_utf8* [Bug 783351]
• gvariant: Optimize (de)serialization of arrays with type-signature “ay” [Bug 772426]
• Added –gresourcesdir switch, making easy to use gresg to autogenerate XML resource files in out of tree builds [Bug 783133]
• Bindings updates
• Gtk+ 4.0 bindings updates
• codegen: Use *_free_full to free GLib.List, GLib.SList and GLib.Queue
• Require and target GLib >= 2.40 [Bug 782005]
• gdbus: Don’t leak nested HashTable on deserialization and make sure types derived from string are freed, e.g. ObjectPath [Bug 782719]
• codegen: Fix finally blocks with async yields [Bug 741929]
• compiler: Add –color=WHEN option following the format of other tools like diff and git-diff.
• glib-2.0: Add quark() functions to errordomains
• vala: Handle non-null in coalescing expression [Bug 611223]
• glib-2.0: Add bindings for g_ptr_array_find/_find_with_equal_func()

For me, create GTK+ custom widgets is a very common task. Using templates for them, too.

Use GTK+ widgets defined by UI XML files, may be created by Glade, is a powerful feature.

Once you create your UI file, you should add it to a gresource XML file too, in order to use glib-compile-resources to compile an embed, if you wish, in your binaries.

Once your project is big enough, you may fall in a large gresource XML file. Regenerate compiled resources based on resources changes, can be tricky, and a hand work.

So I’ve created gresg, a tool to generate automatically an XML gresource file based in a list of files to be compiled with glib-compile-resources. This will help you to trigger a rebuild of compiled resources at any time you make changes in your files.

gresg, is written in Vala and uses GXml to generate XML resources files. As you can see in gresg’s repository, is a very small program.

If you are using Meson you can create a custom target to generate your XML resources, but you need this patch applied to Vala to take all its advantages and automatic re-build of resources.

After a call, Yannick has pushed a patch to add Meson build system to GXml. This is my first time using Meson and I really love it.

After a set of patches, I’ve managed to fix most installation and Unit Test integration.

Meson is well documented and provides a clean syntax.

Vala support is really good. In Autotools I’ve added some obscure rules to fix some old bugs. With Meson GXml has just a few ones, no obscure, commands in order to build Vala documentation and GObject Introspection binary files.

Meson exposes a bug in TDocument parsing, same test pass without error in Autotools. Using mesontest --gdb I was able to run tests in gdb, making things much convenient to debug than in Autotools, unless for the way I managed to debug in the past.

Meson is really fast! This will improve my development/tests/back to development processes, reducing time.

Next step is to find a way to get GXml compiled under Visual Studio, but first Gee needs to get Meson support too.

This cycle Vala have received a lot of love from their users and maintainers. Users and maintainers, have pushed hard to get a lot of bug fixes in place, thanks to a lot of patches attached to bug reports.

List of new features an bug fixes are in NEWS file in repository. Bindings have received lot of fixes too, checkout them and see if you need a workaround.

Many thanks to all contributors and maintainers for make this release a big one.

Highlights

• Update manual using DocBook from wiki.gnome.org as source [#779090]
• Add support for array-parameters with rank > 1 in signals [#778632]
• Use GTask instead of GSimpleAsyncResult with GLib 2.36/2.44 target [#763345]
• Deny access to protected constructors [#760031]
• Support [DBus (signature = …)] for properties [#744595]
• Add [CCode (“finish_instance = …”)] attribute [#710103]
• Support [HasEmitter] for vala sources [#681356]
• Add support for the \v escape charactor [#664689]
• Add explicit copy method for arrays [#650663]
• Allow underscores in type parameter names [#644938]
• Support [FormatArg] attribute for parameters
• Ignore –thread commandline option and drop gthread-2.0 references
• Check inferred generic-types of MemberAccess [#775466]
• Check generic-types count of DelegateType [#772204]
• Fix type checking when using generics in combination with subtype [#615830]
• Fix type parameter check for overriding generic methods
• Use g_signal_emit where possible [#641828]
• Only emit notify of properties if value actually changed [#631267] [#779955]
• Mark chained relational expressions as stable [#677022]
• Perform more thorough compatibility check of inherited properties [#779038]
• Handle nullable ValueTypes in signals delegates properly [#758816]

In my recent private developments, I need to create Gtk+ widgets libraries, and test them before use them in applications.

There are plenty of efforts to provide automated GUI testing, this is another one working in my case, I would like to share. It is written in Vala, is a GTK+ library with just one top window, you can attach your widget to test, can add test cases, check status and finish by calling asserts. Feel free to ask any thing you need or add issues, in order to improve it.

Sorry if the name is too GTKish and some one would like to change it to avoid any “Official Backup from GNOME”, which is not the case.

Hope to improve this library, adding more documentation in order to help others to use it, if they found useful.

Enjoy it at GitHub.

New version of GXml is in place.

No great changes over DOM4 and previous implementations was made. So you can sleep, because your application will run, may be, just with few changes.

A new more powerful, less footprint and good performance implementation of DOM4 has arrived. It is prefixed Gom. This new implementation will be used for all my projects now and on. It provides better implementation of namespaces and avoids using libxml2 tree internally.

Future plans may involve to implement a kind of Gee.Promise objects, in order to parse XML in parallel or to parse large files. Ideas are welcome.

More improvements on XSD parser will come, to provide good API to access this kind of documents; even better, validate your XML files, a feature just partially implemented in libxml2.

I would like to see if some one wants to help porting W3C XPath or XQuery specification using GOM and DOM4, this will be easy with current infrastructure.

GSVG will be ported to GOM, because GOM was inspired by W3C API specification for SVG requirement of DOM4. For now GSVG will be for XML parsing and editing, bu may in the future some one wants to add Cairo rendering and help to create next GNOME canvas using SVG format.

I would like help to port LibreSCL to GOM, I can pay for.

Yes is time to consider a Vala 1.0 release. Vala 0.34 code generator and bindings support LTS versions of GTK+ 3.22 and GLib 2.50. Next stable version of GTK+ will be 4.0 and GLib 2.x, but they have to traverse through 3.9x versions and any GLib 2.x on the way. Reaching that point we can consider Vala 2.0 release.

Traditionally a new Vala version is released along with GLib and GTK+, with bindings updates, from them and other projects. Some times, is necessary to change some Vala syntax or implementations, like threats, in order to be in sync with current GLib/GObject/GIO features. Because this, may we can consider to increase Vala API each stable version of GTK+.

In order to reach Vala 1.0, may we should identify stoppers bugs before to go. Some of them can be related to GNOME Builder, but may is not a real problem is you don’t use it for Vala development. I really would like to file, find and send patches for some of them, producing warnings at C compilation, for a better experience.

A road map could be stated at Vala’s Wiki, in order to track that stopper bugs/features to fix/implement before 1.0 release. This will mark a good stand point for any developer using Vala.

Debian is around corner. It supply Vala 0.34, then it should be considered, and backport fixes, as a LTS version.

Vala provides you a way to write C/GObject/GInterface code using a different syntax. Vala doesn’t require to develop a “core library” in order to provide its features. Its “compiler” is not a compiler, is a C code generator.

Vala can’t be compared with Rust, Go, Python, Java or C#, all of them provide their own “core library” in order to provide most of their features, allows you to create modules (like a library) to extend the language for their users consume. Their core generally is written in C, for very basic features, but almost in the language itself.

Vala is different in many different ways to other real programming languages. Vala can’t exists without GLib and GObject. It just wraps that libraries to provide its Object Oriented syntax. It doesn’t provides any feature by it self, just a syntax to use the ones already present in above libraries, a part to provide some convenient methods to reduce coding boilerplate.

GLib, GIO and GObject are C libraries. They are the basis for GNOME, GNOME Shell and any other application using GNOME technologies. GTK+ and any library or application using it, relays on above libraries, they can’t exists without them. VMWare and LibreOffice consume GTK+ and so GLib/GObject.

Vala provides mechanism to create bindings. They are conventions to help Vala’s code generator to produce correct C code to consume any other, apart of GLib/GObject, libraries. It can do better job if the library use GObject.

Vala is not a Language: This is a conclusion after the On Vala article, comparing Vala’s repository’s activity with other real languages.

May we need to add to Vala’s activity, all commits and developers on GLib, GObject, GTK+ and GObject Introspection, because they are, indirectly, supporters of Vala’s features and usefulness; may be we need to consider all other libraries’ activity, like libsoup, libgda, and any other one supporting GObject Introspection, because they can be consumed by Vala; this is specially true if we consider their support to generate, automatically, Vala bindings.

Considering all of these, if Vala was a real language: it can be considered to be one with a very reach, secure and stable “core”, with years of development behind; with a reach set of other libraries for your use, as a developer, to choose from. But again: Vala is not a Programming Language.

Vala is multiplatform as long as its Code Generator and their libraries it depends on, or can bind, are present in your target platform: Windows and OS X, are just examples.

May is time to update Vala’s README and vala.doap at git.gnome.org, in order to avoid missunderstandings.

With lot of work to do on XSD, but certainly happy to see GXml.Gom* classes taking shape, fixed lot of bugs since last 0.13.2 and starting to port some projects to this new version, I hope to soon release 0.14, just after most translation are in place.

This new version, will provide a better supported XML GObject wrapped, using DOM4 API and initials of other technologies like XPath and XSD.

Hope some one takes some time to implement XPath recent W3C specification and complete XSD support implementation. May be this will be a good projects for Google Summer of Code 2017.

On the process, I’ll try to implement W3C SVG API using GXml.Gom* classes, to provide a fully supported XML/SVG API using GObject libraries, and all other languages supported by GObject Introspection.

Future GXml versions, can include:

• Cleanup more interfaces/classes no useful any more, like TNode derived classes and other non DOM4 compliant interfaces. This will reduce number of classes to choose from, while recommend way will be on GNode and GomNode derived classes.
• Improve XSD support
• Explore how to manage large XML files
• Improve XPath support
• Explore XQuery

May be other ideas, from GXml users.

I love GInterface definitions, more in Vala, because they are clean an easy to describe API. Interfaces are the way W3C defines their specifications, like SVG and DOM4.

Vala interfaces definition are realy close to be a copy and paste from W3C’s specification definitions. With some, well a bit, work, you can transform them in usable GObject Interfaces definitions.

GXml take DOM4 interfaces and implement them, using a set of instantiable classes.

GXml provides a GObject to XML and back serialization framework, allowing you to define your own classes and how you want your data is represented in XML.

In order to read back your information, GXml needs to create, on-the-fly, instances of your classes, this means you need GObject ones no GInterface.

Starting to implement XSD support in GXml, I’ve created a set of interfaces to interpret W3C specification, this is really helpful, but unusable when you need to instantiate an object it is declared as a Interface. For example, if you have an interface A and it has a property of type B, but at the same time B is a GInterface, you can’t implement A and have an instantiable object from B: I mean, using g_object_new().

Because GXml engine, requires instantiable objects, to create new element nodes when found, using a GObject type to parse attributes to properties, for example, I ended creating a set of interfaces, to help me design an clean API, makes room for other implementations engines, but creating a new classes that will implement XSD interfaces having its own “mirror” properties.

This is, while GXml.XsdSchema have a GXml.XsdListSimpleTypes property to access to all simple type definitions, GXml.GomXsdSchema will have two properties with same purpose: a GXml.GomXsdListSimpleTypes property AND a property of type GXml.XsdListSimpleTypes to fully implement GXml.XsdSchema. Second one, will mirror the first. These is more work to implement an interface but keeps your classes’ properties instantiable, and your users can choose to use just GXml.XsdSchema interfaces API to access your class implementation, keeping open to use different implementations.

Best of all, with GXml implementation of XML to GObject, more clearly using GXml.Gom* classes, you will have access to *all* nodes, attributes and child ones found in an XML file, without loose them in the process of de-serializing back to your class instance.