### Lifecycle management
-- [Application Framework](../../04_Developer_Guides/01_Application_Framework/01_Introduction/)
+- [Application Framework](Application_Framework/01_Introduction.md)
started, among other things.
Management of applications, starting, running and stopping them is done in AGL
-with AppFW [Application Framework Management](../04_Developer_Guides/01_Application_Framework/01_Introduction.md),
+with AppFW [Application Framework Management](Application_Framework/01_Introduction.md),
which is an umbrella name to denote the suite of tools and daemons that handle
all of that. It is integrated with systemd and with the current security model.
Applications can use AppFW to hang off data, and to pass it down to
+++ /dev/null
----
-title: Application Framework
----
-
-# AppFW
-
-FIXME.
the one would list out applications and handling start-up.
AGL also provides reference implementations whenever possible and relevant,
-located in the [meta-agl](/04_Developer_Guides/02_AGL_Layers/02_meta_agl/)
+located in the [meta-agl](../../04_Developer_Guides/02_AGL_Layers/02_meta_agl.md)
layer under `meta-app-framework`. At the moment, the Application Framework
contains 2 such components:
Each service should be represented by a `systemd` unit file installed to the
appropriate location. More details can be obtained from the [Creating a New
-Service](../03_Creating_a_New_Service/) document.
+Service](03_Creating_a_New_Service.md) document.
# User session management
- be notified when applications are started or terminated
`applaunchd` with the D-Bus interface is described with more details in
-[the following document](../02_Application_Startup_Dbus/).
+[the following document](02_Application_Startup_Dbus.md).
Application start-up, activation and application switching are sometimes
conflated into a single operation but underneath some of these are distinct
steps, and a bit flaky in some circumstances.
-The [AGL compositor](../../06_Component_Documentation/02_agl_compositor/) has
+The [AGL compositor](../02_agl_compositor.md) has
some additional events which one can use when creating an application
start-up & switching scheme in different run-times.
The `started` event can be used in correlation with the `StartApplication`
method from `applaunchd` such that upon received the `started` even, it can
explicitly activate that particular appid in order for the compositor to
-display it. See [AGL compositor](../../06_Component_Documentation/02_agl_compositor/)
+display it. See [AGL compositor](../02_agl_compositor.md)
about how activation should be handled.
*Note: These can only be received if by the client shell which binds to the
Here's the state diagram for the Qt homescreen implementation of the
application start-up:
-
+
### Application switching
the run-time/shell-client and have a handler that would ultimately activate the
application ID.
-
+
*Note: In practice, the run-time/shell-client would subscribe to both `applaunchd`
and to the AGL compositor, either Wayland native events, or using the gPRC-proxy
*Note: The that the D-Bus interface is in deprecation phase and for the time
being only available for application & services that still rely on them. Once
we migrate everything to gRPC, we will remove D-Bus IPC support. Please see
-[Application Startup with gRPC](../02_Application_Startup/) for the latest
+[Application Startup with gRPC](02_Application_Startup.md) for the latest
information*
# Introduction
In order to provide a language-independent interface for applications and service to
use, AGL includes `applaunchd`, a user service part of the default session.
-*Note: as mentioned [previously](../01_Introduction/), services are managed using `systemd`
+*Note: as mentioned [previously](01_Introduction.md), services are managed using `systemd`
and are therefore not in the scope of this document.*
# Application launcher service
to avoid potential name collisions and ease D-Bus integration.
The application ID is set in the desktop entry file itself for
-[graphical applications](/04_Developer_Guides/03_Creating_a_New_Application_Dbus/#graphical-applications):
+[graphical applications](04_Creating_a_New_Application_Dbus.md#graphical-applications):
it is the value of the `StartupWMClass` field, which must be identical to the `app-id`
advertised through the Wayland XDG toplevel protocol. In case this field is missing
(as is usually the case for non-graphical application), the application ID will be the
```
The `WantedBy=agl-session.target` indicates the service is part of the default AGL
-user session, as mentioned in the [Application Framework](../01_Application_Framework/01_Introduction/#user-session-management)
+user session, as mentioned in the [Application Framework](01_Introduction.md#user-session-management)
documentation.
The `Restart=on-failure` directive ensures the service will be automatically
- Graphical interface allowing user to interact with.
Applications are executed by `applaunchd`, the AGL
-[application launcher service](../01_Application_Framework/02_Application_Startup_Dbus/).
+[application launcher service](02_Application_Startup_Dbus.md).
# Basic requirements
# D-Bus activation
-Similarly to [services](../02_Creating_a_New_Service/#d-bus-activation), applications can
+Similarly to [services](03_Creating_a_New_Service.md#d-bus-activation), applications can
also be activated through D-Bus.
Such applications must name their `.desktop` file after the D-Bus name they register. In addition,
Code Review / AGL / documentation.git / commitdiff
