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?
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 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
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.
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.
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.
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.
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.
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.
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 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.
