A gio.application.Application is the foundation of an application. It wraps some
low-level platform-specific services and is intended to act as the
foundation for higher-level application classes such as
gtk.application.Application or MxApplication. In general, you should not use
this class outside of a higher level framework.
Another feature that gio.application.Application (optionally) provides is process
uniqueness. Applications can make use of this functionality by
providing a unique application ID. If given, only one application
with this ID can be running at a time per session. The session
concept is platform-dependent, but corresponds roughly to a graphical
desktop login. When your application is launched again, its
arguments are passed through platform communication to the already
running program. The already running instance of the program is
called the "primary instance"; for non-unique applications this is
always the current instance. On Linux, the D-Bus session bus
is used for communication.
The use of gio.application.Application differs from some other commonly-used
uniqueness libraries (such as libunique) in important ways. The
application is not expected to manually register itself and check
if it is the primary instance. Instead, the main() function of a
gio.application.Application should do very little more than instantiating the
application instance, possibly connecting signal handlers, then
calling gio.application.Application.run. All checks for uniqueness are done
internally. If the application is the primary instance then the
startup signal is emitted and the mainloop runs. If the application
is not the primary instance then a signal is sent to the primary
instance and gio.application.Application.run promptly returns. See the code
examples below.
If used, the expected form of an application identifier is the
same as that of a
D-Bus well-known bus name.
Examples include: com.example.MyApp, org.example.internal_apps.Calculator,
org._7_zip.Archiver.
For details on valid application identifiers, see gio.application.Application.idIsValid.
On Linux, the application identifier is claimed as a well-known bus name
on the user's session bus. This means that the uniqueness of your
application is scoped to the current session. It also means that your
application may provide additional services (through registration of other
object paths) at that bus name. The registration of these object paths
should be done with the shared GDBus session bus. Note that due to the
internal architecture of GDBus, method calls can be dispatched at any time
(even if a main loop is not running). For this reason, you must ensure that
any object paths that you wish to register are registered before #GApplication
attempts to acquire the bus name of your application (which happens in
gio.application.Application.register). Unfortunately, this means that you cannot
use property@Gio.Application:is-remote to decide if you want to register
object paths.
As the name indicates, the platform data may vary depending on the
operating system, but it always includes the current directory (key
cwd), and optionally the environment (ie the set of environment
variables and their values) of the calling process (key environ).
The environment is only added to the platform data if the
gio.types.ApplicationFlags.SendEnvironment flag is set. gio.application.Application subclasses
can add their own platform data by overriding the
vfunc@Gio.Application.add_platform_data virtual function. For instance,
gtk.application.Application adds startup notification data in this way.
To parse commandline arguments you may handle the
signal@Gio.Application::command-line signal or override the
vfunc@Gio.Application.local_command_line virtual funcion, to parse them in
either the primary instance or the local instance, respectively.
gio.application.Application is the core class for application support.
A gio.application.Application is the foundation of an application. It wraps some low-level platform-specific services and is intended to act as the foundation for higher-level application classes such as gtk.application.Application or MxApplication. In general, you should not use this class outside of a higher level framework.
gio.application.Application provides convenient life-cycle management by maintaining a "use count" for the primary application instance. The use count can be changed using gio.application.Application.hold and gio.application.Application.release. If it drops to zero, the application exits. Higher-level classes such as gtk.application.Application employ the use count to ensure that the application stays alive as long as it has any opened windows.
Another feature that gio.application.Application (optionally) provides is process uniqueness. Applications can make use of this functionality by providing a unique application ID. If given, only one application with this ID can be running at a time per session. The session concept is platform-dependent, but corresponds roughly to a graphical desktop login. When your application is launched again, its arguments are passed through platform communication to the already running program. The already running instance of the program is called the "primary instance"; for non-unique applications this is always the current instance. On Linux, the D-Bus session bus is used for communication.
The use of gio.application.Application differs from some other commonly-used uniqueness libraries (such as libunique) in important ways. The application is not expected to manually register itself and check if it is the primary instance. Instead, the main() function of a gio.application.Application should do very little more than instantiating the application instance, possibly connecting signal handlers, then calling gio.application.Application.run. All checks for uniqueness are done internally. If the application is the primary instance then the startup signal is emitted and the mainloop runs. If the application is not the primary instance then a signal is sent to the primary instance and gio.application.Application.run promptly returns. See the code examples below.
If used, the expected form of an application identifier is the same as that of a D-Bus well-known bus name. Examples include: com.example.MyApp, org.example.internal_apps.Calculator, org._7_zip.Archiver. For details on valid application identifiers, see gio.application.Application.idIsValid.
On Linux, the application identifier is claimed as a well-known bus name on the user's session bus. This means that the uniqueness of your application is scoped to the current session. It also means that your application may provide additional services (through registration of other object paths) at that bus name. The registration of these object paths should be done with the shared GDBus session bus. Note that due to the internal architecture of GDBus, method calls can be dispatched at any time (even if a main loop is not running). For this reason, you must ensure that any object paths that you wish to register are registered before #GApplication attempts to acquire the bus name of your application (which happens in gio.application.Application.register). Unfortunately, this means that you cannot use property@Gio.Application:is-remote to decide if you want to register object paths.
gio.application.Application also implements the gio.action_group.ActionGroup and gio.action_map.ActionMap interfaces and lets you easily export actions by adding them with gio.action_map.ActionMap.addAction. When invoking an action by calling gio.action_group.ActionGroup.activateAction on the application, it is always invoked in the primary instance. The actions are also exported on the session bus, and GIO provides the gio.dbus_action_group.DBusActionGroup wrapper to conveniently access them remotely. GIO provides a gio.dbus_menu_model.DBusMenuModel wrapper for remote access to exported gio.menu_model.MenuModels.
Note: Due to the fact that actions are exported on the session bus, using maybe parameters is not supported, since D-Bus does not support maybe types.
There is a number of different entry points into a gio.application.Application:
The gio.application.Application.startup signal lets you handle the application initialization for all of these in a single place.
Regardless of which of these entry points is used to start the application, gio.application.Application passes some ‘platform data’ from the launching instance to the primary instance, in the form of a glib.variant.VariantG dictionary mapping strings to variants. To use platform data, override the vfunc@Gio.Application.before_emit or vfunc@Gio.Application.after_emit virtual functions in your gio.application.Application subclass. When dealing with gio.application_command_line.ApplicationCommandLine objects, the platform data is directly available via gio.application_command_line.ApplicationCommandLine.getCwd, gio.application_command_line.ApplicationCommandLine.getEnviron and gio.application_command_line.ApplicationCommandLine.getPlatformData.
As the name indicates, the platform data may vary depending on the operating system, but it always includes the current directory (key cwd), and optionally the environment (ie the set of environment variables and their values) of the calling process (key environ). The environment is only added to the platform data if the gio.types.ApplicationFlags.SendEnvironment flag is set. gio.application.Application subclasses can add their own platform data by overriding the vfunc@Gio.Application.add_platform_data virtual function. For instance, gtk.application.Application adds startup notification data in this way.
To parse commandline arguments you may handle the signal@Gio.Application::command-line signal or override the vfunc@Gio.Application.local_command_line virtual funcion, to parse them in either the primary instance or the local instance, respectively.
For an example of opening files with a gio.application.Application, see gapplication-example-open.c.
For an example of using actions with gio.application.Application, see gapplication-example-actions.c.
For an example of using extra D-Bus hooks with gio.application.Application, see gapplication-example-dbushooks.c.