Vala state: October 2018

Maintainability

While I think maintainability could be improved, adding to history commits from contributions, apart from the ones coming from current Maintainer. Actually, there are some lot of commits not in history coming from authors outside current ones. Hope with new GitLab GNOME’s instance, this will reflect the correct situation.

Behind scenes, Vala has to improve its code base to adapt to new requirements like to develop a descent Vala Language Server and more IEDs supporting Vala. At least for me, even GEdit is productive enough to produce software in Vala, because the language itself; write a Class, an Interface and implement interfaces, is 10 times faster in Vala than in C.

Vala has received lot of improvements in last development cycles, like a new POSIX profile, ABI stability, C Warnings improvements and many other, to be reported in a different article.

Look at Vala’s repository history, you will see more “feature” commits than “bindings” ones, contrary to the situation reported by Emmanuel, while should be a good idea to produce a graphic on this, but resent improvements could tell by them self the situation has been improved in recent release cycles.

Lets look at repository’s chart. It reports 2000 commits in the last 3 months, 1.1 average per day, from 101 contributions as for October 19, 2018. Me at 10 commits from the last year, so I’m far to be a core contributor, but push ABI stability to be a reality. My main contributions are to communicate Vala advances and status.

Vala as a language

Vala has its roots as a GObject oriented language. Currently for C too, because it can produce C code without dependent on GLib/GObject.

Program a C code base using an Object Oriented Programming is easy on Vala, even if the C output are GObject classes or not. You can produce Compact Classes, as for  Vala’s Manual:

Compact classes, so called because they use less memory per instance, are the least featured of all class types. They are not registered with the GType system and do not support reference counting, virtual methods, or private fields. They do support unmanaged properties. Such classes are very fast to instantiate but not massively useful except when dealing with existing libraries. They are declared using the Compact attribute on the class

In C a compact class is a simple struct, its fields can have accessors, so your users just call a get/set method to access it and run additional code when is done. Following code:

[vala]
[Compact]
class Caller {
  public string _name;
  public string name {
    get {
      return _name;
    }
    set {
      _name = value;
    }
  }
  public void call (string number) {}
}
[/vala]

Is translated to:

<br />
#include &amp;lt;glib.h&amp;gt;<br />
#include &amp;lt;glib-object.h&amp;gt;<br />
#include &amp;lt;stdlib.h&amp;gt;<br />
#include &amp;lt;string.h&amp;gt;</p>
<p>typedef struct _Caller Caller;<br />
#define _g_free0(var) (var = (g_free (var), NULL))</p>
<p>struct _Caller {<br />
	gchar* _name;<br />
};</p>
<p>void caller_free (Caller * self);<br />
static void caller_instance_init (Caller * self);<br />
void caller_call (Caller* self,<br />
                  const gchar* number);<br />
Caller* caller_new (void);<br />
const gchar* caller_get_name (Caller* self);<br />
void caller_set_name (Caller* self,<br />
                      const gchar* value);</p>
<p>void<br />
caller_call (Caller* self,<br />
             const gchar* number)<br />
{<br />
	g_return_if_fail (self != NULL);<br />
	g_return_if_fail (number != NULL);<br />
}</p>
<p>Caller*<br />
caller_new (void)<br />
{<br />
	Caller* self;<br />
	self = g_slice_new0 (Caller);<br />
	caller_instance_init (self);<br />
	return self;<br />
}</p>
<p>const gchar*<br />
caller_get_name (Caller* self)<br />
{<br />
	const gchar* result;<br />
	const gchar* _tmp0_;<br />
	g_return_val_if_fail (self != NULL, NULL);<br />
	_tmp0_ = self-&amp;gt;_name;<br />
	result = _tmp0_;<br />
	return result;<br />
}</p>
<p>void<br />
caller_set_name (Caller* self,<br />
                 const gchar* value)<br />
{<br />
	gchar* _tmp0_;<br />
	g_return_if_fail (self != NULL);<br />
	_tmp0_ = g_strdup (value);<br />
	_g_free0 (self-&amp;gt;_name);<br />
	self-&amp;gt;_name = _tmp0_;<br />
}</p>
<p>static void<br />
caller_instance_init (Caller * self)<br />
{<br />
}</p>
<p>void<br />
caller_free (Caller * self)<br />
{<br />
	_g_free0 (self-&amp;gt;_name);<br />
	g_slice_free (Caller, self);<br />
}<br />

Could you find some improvements in C code generation?

As you can see, Vala generates code to create your struct, access your fields while run costume code, to free your struct and initialize it. Your C users will have a clean and easy API to use, as you expect, your struct.

If you use Vala to access your C struct, also written in Vala, it will create and free correctly automatically.

So,

Less code, more features.

Vala Pushing up Complex projects

GObject/GInterface are a powerfull tool, but is really hard to use in C if you have to write and implement a complex hierarchy of classes and interfaces. W3C DOM4, is a clear example of it; sure is possible implement in C, but is hundred times easy to implement and maintain in Vala.

GXml and GSVG are an example on how complex a hierarchy can be, and how they have been implemented in a short time.

GXml’s GomElement hierarchy just shows all interfaces it should implement to be DOM4’s Element.

Have you tried to write lot of fragmented featured interfaces in C and implement all of them in a single GObject class?

W3C SVG 1.1 specification have lot of interfaces to write and implement to have a fully compliant object’s class.

Implement GSVG over Vala, makes SVG 1.1 possible in a short time; but don’t stop here, because maintain this complex hierarchy, like move an object from final to derivable one, or move methods from a final to parent class, including its interface implementation, is hundred times easy to do in Vala than in plain C/GObject.

Vala allows: Complex Interface hierarchy implementation easy

While GSVG implementation is not completed, Vala is the right tool to use on this kind of projects.

Vala libraries are Introspectable and usable in other languages

Yes, C GObject classes are introspectable, but lot of annotations are required to produce GIR/TYPELIB, usable in Python or JavaScript.

Vala code produce Introspection Annotations as you write. Produce GIR XML file format is a matter to use --gir switch. Errors and warnings in Vala are focused to make your classes introspectable consistent; for example, you can’t return NULL in Non NULL declared methods.

Vala Scripting?

Vala Language Server

I’m working with a library called GNOME Vala Language Server (GVls), as a proof of concept for a server that will serve autocompletion, syntax highlighting and that kind of stuff, but found something interesting by accident.

I’ve added an interface called Client, may is not it final name, but it allows to locale a symbol in a already parsed file, along with some goodness from other interfaces and implementations, I’ll talk about in another article.

The Accident

While trying to create a in-line parser to detect if the actual word is an object or any other kind of symbol to, in the near future, propose a list of properties and methods or a list of method’s parameters, by accident Client now can parse in-line Vala code, so you push text to this Client object and a Server (the object that parse and handle Symbol collection), parse  it and just add new Symbols to its collection, without any effort or parse errors for incomplete code!!!!

So now if you push the folowing text:

class Push {\n

Server now find a Push symbol representing a new Vala class. Inserting a medhod:

public void callme () {

You can find in the Server a new symbol for Push.callme method. Just no error, even if the code is not completed yet.

Vala Scripting?

Well not for now. But with this work the doors are opening. This include Genie, because it has more script suitable syntax than Vala. Any way, leave to the time and some others’ help of course.

GDA 6.0 progress

GDA project has released 5.2.5 and tagged 5.2.6, with some improvements, but the real work is on master.

Master is targeting 6.0, a new ABI/API release, providing better GObject Introspection support and code modernization.

A new Meson build system is on the way to replace Autotools. Meson helped to implement, fix and test all changes in less time. Like on multi-threading, where is more easy to produce multiple parallel tests, helping to expose issues to fix. Master have big improvement on that matter.

API is almost the same with minor changes, so port to new one should be easy. Major API breaks will happen on 7.0 development cycle.

GDA have really old code, modernization of public API has been the priority; but, some parts are very sensitive to the change, so they may never will change or will wait to 7.0 cycle.

GDA’s GTK+ widgets, has been ported to avoid Deprecated API by recent 3.x releases. No heavy changes here, apart of the code modernization. GDA’s Control Center and Browser, has been fixed, so they are back from the dead. There are other, more modern applications out there like Sequeler, so in the short term may this tools old will be removed, unless there are interest by users.

My experiment on mix Vala code with C source in GDA should wait, but I found it functional, just some improvements in Vala code generation adding C source documentation are required.

Beyond 6.0, there are interest in improve implementation of new database Providers. At first, I’ve tried to make more deep changes in API to make room for a new providers platform, but the way current one and connection objects are tied each other makes that hard, so I decided to wait until 7.0 cycle starts.

In parallel, I’m developing a new Vala library called libvda, to experiment with a new platform for providers. It is exposing a set of interfaces, making more easy to have new providers; load them thought libpeas is planned.

Currently libvda has objects to connect to PostgreSQL and SQLite, using a common GDA provider object; add more existing GDA’s providers is a matter of a really few lines of code, thanks to Vala.

Because GDA has a very slow mechanism to generate Meta information about data base’s objects, I plan to expose meta queries directly, so they can be used faster. libvda, expose interfaces to access meta information using a GObject API, but there is a new DDL module in GDA for meta information, but that is another history for a different article.

Design and implement interfaces an objects in Vala is about 8 to 10 times faster, considering API changes in the development process. This is why I can expend time on libvda, to check out how could be on GDA and why I’m considering to mix Vala source code with C one.

Vala+GDA: An experiment

I’m working on GNOME Data Access, now on its GTK+ library, specially on its Browser, a GTK+ application more as a demo than a real database access tool.

GDA’s Browser, spots notable features in GDA’s non-GUI library. For example, support to create a single connection binding for two or more connections to different databases and from different providers (SQLite, PostgreSQL, MySQL), so you can create a single query and get a table result combining data from different sources. More details in another post.

The Experiment

Browser is getting back to life, but in the process I found crashes here and there. Fix them requires to walk around the code, found lots of opportunities to port it to new available technics to define GObject/GInterface API. Do that work may it’s too much work for a single man.

So, What about to use Vala to produce C code faster in order to rewrite existing or new objects?

This experiment, will be for 7.0 development cycle. For next 6.0 release, I would like to fix bugs as far as possible.

This experiment may help to answer another question: Is possible to port Vala code to C in order to be accepted by upstream projects like GXml’s DOM4 API to GLib?

GNOME Data Access 6.0

At master there are a set of fixes for GDA Library and its GTK+ widgets, its Control Center for Data Sources Management and its powerful GDA Browser.

Next major 6.0 release, is breaking API/ABI from older releases, in order to improve GObject Introspection bindings, including Vala ones.

One step forward to use Meson build system, has been done too. Indeed, that work helps to speed up development.

Please tryout GDA Graphical User Interfaces, that will expose more and issues, before a final release.

Screenshots

GDA Browser Initial Connection:

Gda Browser Adding values to a Data Base Table:

Gda Browser Data Manager using a Table as Source:

Gda Browser running SQL queries, this include any other like select, create databases, create tables and views, insert data, and any other supported by the provider.

GDA Control Center, allows to pre-configure, connections to data baser server, to save all required connection parameters, with an easy to use UI:

Use in your application

All above screenshots, use a set of pre-defined GTK+ 3.0 widgets, so you can embed any of them in your own application, while GDA Browser, still powerful, is just for demonstration.

Vala 0.41.90 Released

Vala development has never been stopped. New features and better code generation is present in recent development version.

This is like a “Beta” version, so go ahead and test with your new code.

Checkout that now is possible to annotate an automatic property, with a [GtkChild] attribute, making possible to bind directly your XML builder defined widget to your class, so is easy to create powerful custom widgets.

Also checkout Vala deprecations remove <= 0.22, so your Vala code could fail to compile. Just port to new API bindings.

From release notes:

  • Reintroduce POSIX profile (No GLib/GObject dependency!)
  • parser: Add support for explicit unlock syntax
  • vala: Support anonymous definitions of delegates in bindings
  • codegen: Support automatic properties as GtkChild (makes easy create custom GTK+ widgets)
  • codegen: Apply G_PARAM_EXPLICIT_NOTIFY on properties with “notify = false”
  • codegen: Drop support for non-auto property initializer in gobjects
  • codegen: Avoid using deprecated “g_type_class_add_private”
  • vala: Constants and signals are not lockable
  • codegen: Don’t apply ref_sink_function if target_type is floating_reference
  • vala: Treat floating method-return-type as nullable if error may be thrown
  • vala: Transfer floating-reference attribute while casting – analyzer: Break cyclic references of BasicBlock
  • vala: Break reference chain between DataType and Symbol if possible
  • codegen: Fix invocation of abstract/virtual methods with NoWrapper in compact classes
  • vala: Report error for invalid base access in method/property of compact class
  • libvaladoc: Replace void* with corresponding Vala API
  • codegen: Don’t include the full absolute path in line directives
  • codegen: Add source_reference to unsupported floating reference error

Updated Bindings include:

  • gobject-2.0: Make GLib.Signal a struct of uint and bind g_signal_new*
  • clutter-1.0: Change type of Clutter.Key.* constants to uint
  • gdk-3.0: Change type of Gdk.Key.* constants to uint
  • gtk+-4.0: Change type of Gdk.Key.* constants to uint
    gstreamer: Update from 1.15+ git master
  • webkit2gtk-4.0: Add JSC namespace to javascriptcoregtk-4.0 and fix depends
  • Remove clutter-gst-1.0, GStreamer 0.10, rest-0.6,
    tracker-indexer-module-1.0, libsoup-2.2, gdu and gdu-gtk,
    twitter-glib-1.0, mx-1.0
  • Remove vala-specific deprecations <= vala-0.22

SVG Rendering and GSVGtk

For SVG rendering, we have few options: librsvg, as the most popular one,,and Lasem, maybe others. Both take an SVG file, parse it and render it over specified Cairo.Context.

GSVGtk is using librsvg by default, but have started to experiment with a new Rendered, written in Vala and using GSVG objects directly.

Using GSVG objects directly, means you can create programmatically an SVG image, then pass it directly to GSVGtk’s Renderer to render it to screen, create an image or a PDF, without write down to an string and then parse back in the renderer.

GSVGtk’s renderer, is not a fully compliant SVG 1.1 specification. It is enough for basic shapes and texts. Needs transformations at least for a more useful renderer for a canvas user like libgtkcanvas.

GSVGtk’s new renderer is in render branch if you want to try it.

For some reason libgrsvg creates an translucent area, while GSVGtk’s renderer is not, so in the video you can see how each shape is rendered clearly when it is drawn inside a Clutter.Actor, so now with this in shape, is possible to think to add some controls for shape editing in GSVGtk, now that invalidating each actor drawing area allows to render just the object it cares about, but without text intermediate format.

Python for GNOME Mobile?

As you may already know, Python is one of the hottest programming language out there, with thousand of job offerings, so makes sense, at least for me, to push this language as official one for GNOME Mobile applications.

elementary OS is doing a good job on engagement new developers, while use Vala as its official language. For me, Vala is a good candidate for advanced/performance constrained Mobile applications.

Both languages uses GNOME’s technologies, through GObject Introspection. So, any new widget designed for responsive Mobile applications, will be available to Python and Vala.

An old License issue on GLib’s static linking on Android, can be tackled by Purism, in a form of tools to allow a dynamically loaded version. For free software, this is not an issue, but for proprietary one.

Provide a high level programing language, potentially distributed in binary form, could incentive app development.

On Vala side, allowing to develop software in this highly productive GObject focused programing language, can push up games or any performance constrained applications, development offering; while you get all goodness of GObject and C world. Thanks to C, GNOME technologies, are available to many other languages; so, Rust  and C++, could find their own way.

This is just for discussion and a proposal to Mobile OSs, using GObject based software.

GNOME Mobile

For Purism GNOME can be used in Mobile phones, if this is coming to a reality, we all should start to think on how your app will see and behaves in small screens, no just HDPI desktops, there are work in progress to help on these from them.

If GTK+ can provide feedback to know if your app is running in small/phone’s screen, could be easier to react and show an optimized UI version.

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.