The backbone of a Hemera Application

In Hemera, applications can be written in a variety of languages, but have peculiar characteristics in common:

  • Each application is represented by a unique id in the system, in reverse domain name notation.
  • Each application has a manifest (.ha) file, representing its properties.
  • A Hemera Application can live only inside an Orbit. An Orbital Application lives inside its own Orbit.
  • A Hemera Application can be started only via Gravity, and would refuse to start otherwise. In the same fashion, applications not adhering to these concepts, will not be recognized by the system.
  • In case a Hemera Application is written in a framework/programming language which integrates in an event loop, the Application MUST inherit the Application class of the SDK of the framework of choice (the equivalent of Hemera::Application in Qt5).

The .ha file (manifest)

The ha file is arguably the most important file of a Hemera Application. An example is:

import com.ispirata.Hemera.Settings 1.0
Application {
applicationId: "com.myorganization.Project.Application"
name: "Hello World"
description: "My first Hemera Application"
version: "0.1.1"
organization: "My Organization"
}

The ha files deeply integrates with the underlying buildsystem (or creates one, as seen below) to get all the needed information. At the moment, the only supported buildsystem is CMake, with preliminary support for QMake and .pro files. See the CMake manual below for more information.

ha is then compiled into a number of files which constitute the system procedures for starting up the application.

Using ha as a buildsystem

ha files have a set of subclassed Application object which serve as a complete buildsystem, or even as a code generator. The following example illustrates how a simple qml application with no C++ code at all can be created in Hemera.

import com.ispirata.Hemera.Settings 1.0
SimpleQmlApplication {
applicationId: "com.myorganization.Project.MyQmlOnlyApplication"
name: "View my stuff"
description: "A pure Qt Quick2 application"
version: "1.0.0"
organization: "My Organization"
mainQmlFile: "qml/main.qml"
resourceFiles: ["qml/main.qml"
, "qml/AppListDelegate.qml"
, "qml/AppList.qml"
, "images/configure.png"
, "images/go-previous.png"
, "images/tele.png"
, "images/icons/music.png"
, "images/icons/particles.png"
, "images/icons/video.png"
, "images/icons/slideshow.png"
, "images/icons-tilted/music.png"
, "images/icons-tilted/particles.png"
, "images/icons-tilted/video.png"
, "images/icons-tilted/slideshow.png"]
}

This, plus all the files listed in resourceFiles, is all that's needed to have Hemera compile your application. The ha, in this case, generates under the hood a CMake file taking care of building the whole application. Several templates are available, for simple and advanced purposes.

Note
Using ha as a buildsystem is the recommended way to build applications on Hemera.

ha files and Orbital Applications

When building your application from an ha file, your application is made available as an Orbital Application as well. This, unless you specify "orbitalApplication: false" in your ha. Even though the procedure is automatic, you still have to configure the Sandbox features of your application as if it was an Orbit. The semantics are identical - the previous example would then be:

import com.ispirata.Hemera.Settings 1.0
SimpleQmlApplication {
applicationId: "com.myorganization.Project.MyQmlOnlyApplication"
name: "View my stuff"
description: "A pure Qt Quick2 application"
version: "1.0.0"
organization: "My Organization"
features: Features.Audio | Features.Video
mainQmlFile: "qml/main.qml"
resourceFiles: ["qml/main.qml"
, "qml/AppListDelegate.qml"
, "qml/AppList.qml"
, "images/configure.png"
, "images/go-previous.png"
, "images/tele.png"
, "images/icons/music.png"
, "images/icons/particles.png"
, "images/icons/video.png"
, "images/icons/slideshow.png"
, "images/icons-tilted/music.png"
, "images/icons-tilted/particles.png"
, "images/icons-tilted/video.png"
, "images/icons-tilted/slideshow.png"]
}

Which enables the Audio and Video features for your Orbital Application's Sandbox.

A quick CMake guide

Note
If you don't plan on using CMake, or plan on using ha as your buildsystem, you can skip this section.

Integrating Hemera into CMake is as easy as using three macros. An example follows:

find_package(HemeraQt5SDK COMPONENTS Core Gui Widgets REQUIRED)
find_package(CommonModules)
# sources
set(myapp_SRCS
src/myapp.cpp
)
hemera_add_application_properties(myapp_SRCS ${CMAKE_SOURCE_DIR}/com.org.myapp.ha
SimpleApplicationProperties simpleapplicationproperties)
# final lib
add_executable(myapp ${myapp_SRCS})
target_link_libraries(myapp Qt5::Core Qt5::Gui Qt5::Quick Qt5::Qml Qt5::DBus Qt5::Network HemeraQt5SDK::Core HemeraQt5SDK::Gui HemeraQt5SDK::Qml)
# Install phase
hemera_install_application(myapp "com.org.myapp" ${CMAKE_SOURCE_DIR}/com.org.myapp.ha)
include(GitArchive)
# Archive
add_make_dist_target(myapp 0.1.1)

HemeraQt5SDK and CommonModules need to be found. Once done, CMake needs three things:

  • hemera_add_application_properties: Creates the needed C++ logic out of an ha file. The resulting class (SimpleApplicationProperties in this case) will then be passed over to Hemera::Application 's constructor.
  • hemera_install_application: Replaces the install command, and takes the application id and the ha file as an additional parameter. Remember, the id and the name must match!
  • add_make_dist_target: Used by Start! and the local SDK, it packages the application and makes it ready for delivery. To work outside of the local SDK, the application must be committed onto a Git repository.

The make procedure will, then, take care of generating all the needed components.

Note
It is usually advised to rely on ha files for the generation of the CMake logic, unless you have very specific needs.