From Apertis
Jump to: navigation, search


The selection process

For the Apertis SDK, this is how we plan to go about defining the APIs:

  • Contributor proposes a module for the public API, along with a list of objects and methods that should be exposed
  • Collabora goes over the proposed objects and methods making recommendations
  • Contributor applies recommendations and establishes API as public and supported

The APIs will be made available in a language to be decided, using a technique to be decided. Most API will also be made available to a webruntime.

Language of choice

Using C and C++ APIs may be a bit daunting, specially for developers used to more managed, high level languages. That is why every major platform is investing on higher level languages these days: Java, C#, Swift, JavaScript. GNOME has over the last couple of years discussed the matter and decided on using JS as the official language to be recommended for developers to use when writing GNOME applications.

The tool currently in use for GNOME is gjs, which binds GObject APIs to JavaScript through GObject Introspection. The main line of thinking currently is to use GObject Introspection through gjs for making SDK (and system) APIs available. GObject Introspection annotation supports skipping objects and methods, so they can be selectively exported.

Also, GObject Introspection support can also be written for libraries that are not GObject users, such as cairo, which indeed already has introspection support.


Introspection shares some infrastructure with gtk-doc, which is used for building API reference for most GNOME projects. Since gtk-doc understands introspection annotations for a while now, annotations could be added to represent the level of support for a given API, such as unsupported, deprecated, supported, recommended. In fact, annotations do already provide tags such as Since and Deprecated which can be used to indicate from which version a given API item is available or has been deprecated, as well as an Stability tag with values for Stable, Unstable and Private. Those could be used to separate in documentation what should and should not be used.

Web Runtime

We believe using JavaScript for the recommended language would also have the advantage of making it easier to share code for hybrid applications that run under a web runtime with access to platform APIs. Collabora is considering the best solution is probably porting gjs to use JavaScriptCore as its backend. By doing that, only one JS engine will be around and the GObject Introspection support will be the same for both SDK and web runtime. An R&D project is currently researching how hard that port would be. Also important to point out GNOME developers have also expressed interest in having gjs backed by JSC in the past.

Personal tools