Month: August 2016

For an internal application, I’ve created a Gtk.Window derived tester class, added some widgets to show current test, status, number of fails and a Gtk.Grid to attach custom widgets. This class expose some API to set a widget to test, autoclose and some signals you can use to run some tests.

GTK+ custom widget testing is no an easy task, at least it is not integrated into GTK+, making you to figure out how to add public API or signals you can use to connect to test it. Of course, you don’t have to do the same, I just starting to create this tester window class.

My widgets, are in a library then no app is used. I’ve tested each one at a time to check it constructs without warnings, making Unit Test to pass. See my post about this warnings.

Now, when I need to see if my custom widget is showing the correct information, like in a Gtk.TreeView, is hard if you don’t API exposing it; I really don’t want to expose public API to test it, because is not the intention to allow any other to interact with each internal widgets. I’m open to see if this is the correct way to do so, but for now I really would not like to do so.

When testing a GUI widget, you should be inside a GLib loop to catch signals, may be not the only one method. Catch them allows to see if the widget is sending them; if when it is raised is showing correct information to the user (requiring to add public API to access internal widgets), and so on.

I really would like to see GNOME Builder merge my work on templates, I would like to publish this class (written in Vala), to any one to use for its custom widgets testing.

Once, I’ve finished to try to use already existing Gtk.Widget signals and API, I’ll back to suggest one feature to be added to GTK+ to make them testable.

For my GTK+ based library, I use Vala and Glade to create templates for custom widgets with Unit Testing. For some reason I set can_default and has_default to true, this throws a warning message:

Gtk-WARNING **: /build/gtk+3.0-z20Lwo/gtk+3.0-3.20.7/./gtk/gtkwidget.c:8550: widget not within a GtkWindow

That 8550 line is related to method gtk_widget_grab_default, when you create your new custom Gtk.Grid derived widget, before to add it to a Gtk.Window, it calls this method before it has a top level window, sending this warning.

Now, for general GTK+ applications this is not a problem; but for GTK+ libraries trying to add a kind of Unit Testing. GTest will fail your test case, when any warning is raised, then you can’t continue until you fix it.

This is to help any one with same issue and for me for future developments.

Hope to share some of my work to create a custom GTK+ Window widget for custom widget testing using  GTest; stay tuned.

 

When you have developed a library using Vala programing language, or any other language, you should generate documentation about its API. You can use Valadoc to generate Documentation for Vala based libraries.

GXml, is a Vala project using valadoc command line tool and Autotools, to automatically generate its documentation. As you can see in this link, Vala documentation provides a very convenient graph about object’s hierarchy; properties and methods provided by current class; and all inherited properties and methods from base classes and interfaces it implements.

But how can I add this feature to my own Vala project? Well, you can use Autotools to call valadoc, generate your documentation and then install in the system, to be available for GNOME DevHelp to show up locally and, at the same time, in GNOME Builder integrated help facility.

While I haven’t, yet, found the way to generate C API documentation using valadoc, from my Vala API one, I’ll show you, in a second part, how you can do it, but not before I have figured out how to create a mk file you can use in your project for an out-of-the-box procedure.

I’ve recently finished a makefile to make easy to create GTK+ applications as well as GTK+ libraries using Vala programing language.

While Vala allows you to use UI files generated by Glade as templates to create custom widgets, is recommended you add these ui files as resources to your application or library’s binaries, in order to build your User Interface. While Vala custom widgets are out of scope of this post, we will talk about how I’ve created a makefile to be imported into your Makefile.am for GTK+ resources embedding.

vala_gtk.mk, is a file to be included in your Makefile.am, after you include vala.mk or valalib.mk, depending on your project. Use the first for  GKT+ applications; the last when creating UI libraries.

Once this pre-requisites are met, you are ready to set up a GTK+ application, because vala_gtk.mk, adds to your VALAFLAGS the gtk+-3.0 package, but the most important, it adds a reference to the XML file with all your resources to be embedded into your application or library binaries. This is required in order to Vala’s compiler to find all your UI files for widgets templates or simple build using GtkBuilder; also images, and any other kind of file can be added as resource, like licenses, texts, and others.

glib-compile-resources is used to generate a C source code file and its header, for all resources, to compiled with your project’s target. Once it is compiled this way, all your resources will be available using GResource or any other function using GLib resources.

For GNOME Builder, I’ll send a patch for it to add an Autotools template to create both applications and libraries for GTK+ written in Vala with resource compilation support.

May be in the near feature, this file could be splitted to include just resource generation as resources.mk, in order to use it when GTK+ is not used at all, but this is another history and a good reason to write some thing about.

 

Unit testing is one of the most important features you have to write when developing a library. GLib have a test suite and is available for GLib based libraries for a while, and it is available for Vala libraries too.

Now I’ve finished a patch to add Unit Testing to Vala libraries templates in GNOME Builder. Hope it is clean and easy to use, even for other projects not using Builder as primary IDE.

This template should be available on Builder 3.22 and will help you, Vala developer, to setup your Vala libraries easy and start to write down your tests cases for bug hunting, regression-free releases and better experience for your users.

Recently blogged  about make distcheck and Vala libraries and how you can use GNOME Builder for Vala development, both are important for Vala developers expecting to increase its productivity.

As all you know Autotools is hard to learn, or at least takes some time to produce custome build rules. While Vala in Autotools have been there for a while it is buggy, making hard to get a out-of-the-box, clean and easy build system.

Now as part of my work to fix Bug #766621, I was able to produce a clean Makefile.am, with all passing make distcheck. I’ve added some utility makefiles to build libraries with GObject Introspection support out-of-the-box.

Just checkout my test bed project at GitHub, in order to see how simple could be.

GNOME Builder has a template system, really easy to update, and now it will have, as soon as may work on Bug #766621 is accepted to commit, out-of-the-box Vala libraries templates for your pleasure.

GNOME Builder have support to create Vala libraries skeleton using templates, but can’t produce any useful library yet. You can see bugs 766621, 768541, 768740, 768540 and 766621, for missing features.

While my patches to improve Builder’s template system work, they can be used when you try to run make distcheck, due to current Vala support implementation of Automake. See bug GNU bug #13002.

But now I on stub! No one have checked 13002, Christian Hergert  have no time to review my patches, well not all of them and Builder is a big project, and personally I now I’m not good enough on Autotools to create a clean implementation, but with Christian feedback I’ve get my best and will write better cleaner implementation.

Is better to fix Automake Vala implementation, in order to produce clean and easy to write Makefile.am for Vala projects, less code and less work around. All implementation should pass both make check and make distcheck.

If no response found, then may I need to write Autotools macros and mk files to be imported to your Makefile.am file in order to provide a clean implementation and easy to use, only after Autotools is fixed.

This will me help too, to write my own libraries more easy. Now I have to fix manually and find the current configuration for each one, most of the time based on GXml, but is a time consuming task, requires Autotools knowlage and should be fixed each time you added new stuff. I really like libgee’s Makefile.am, which is clean and just works, but all the time I start to use it as template, it just not work for me. Then I think I need to create my own and push it to Builder to produce good templates for all of you too.

If you have been using Gee for a while, you have noticed it produce a lot of warnings not at Vala compilation but at C compilation time.

GXml is using Gee for a while too and we are facing the same. I have some proprietary applications using Gee too.

Recently I started to search the source of these warnings. I found valac producing C code with simple cast to parent but not the  current class, this is:

_tmp25_ = gee_abstract_collection_get_size ((GeeCollection*) _tmp24_);

This function requires to cast to GeeAbstractCollection, this is why we see some of these warnings.

In order to reduce this warnings I started to use “as” operator. When transformed in C, it first check if the object to cast is the type of required one, if not it just pass a NULL pointer, on success it just cast.

Now in my internal code, and soon on GXml, I have used “as” operator, to reduce this C warnings and producing less stress. But at the same time, when you have a C warning, you should fix it, in order to reduce the risk of improper behavior or crash. Now most of you using Gee or GXml, have lot of warnings and you have chosen to ignore them, because is not produced by your code; may in some times is the case, but when you see lot of them, you prefer to ignore all if valac no warns you.

I’m sure we need to change some Vala code at Gee source code level, but that is another history and I’ll go for them, when have time enough; if you can help, please file bugs with patchs and I can help you to push to Gee or GXml, making Vala programming a pleasure as is today.

EDIT:

Ok, it is unexpected, I have to admit, but Gee has a clean compilation without any warning.

At the same time, while changing my own code, found changing simple properties like size to (object as Gee.Map).size is enough to remove annoying warnings, but to get objects on foreach statement you should change from:

foreach (MyObject o in collection_object.values)

to

foreach (MyObject o in (collection_object as Gee.Map<string,CollectionObject>).values)

requiring more work at writing your code time.

Conclusion: This is a valac bug, producing C code without correct casts.