Designated initialiser from the underlying `C` data type.

This creates an instance without performing an unbalanced retain i.e., ownership is transferred to the Application instance.

Designated initialiser from a constant pointer to the underlying C data type. This creates an instance without performing an unbalanced retain i.e., ownership is transferred to the Application instance.

Optional initialiser from a non-mutating gpointer to the underlying C data type. This creates an instance without performing an unbalanced retain i.e., ownership is transferred to the Application instance.

Optional initialiser from a non-mutating gconstpointer to the underlying C data type. This creates an instance without performing an unbalanced retain i.e., ownership is transferred to the Application instance.

Optional initialiser from a constant pointer to the underlying C data type. This creates an instance without performing an unbalanced retain i.e., ownership is transferred to the Application instance.

Optional initialiser from the underlying C data type. This creates an instance without performing an unbalanced retain i.e., ownership is transferred to the Application instance.

Designated initialiser from the underlying C data type. Will retain GtkApplication. i.e., ownership is transferred to the Application instance.

Reference intialiser for a related type that implements ApplicationProtocol Will retain GtkApplication.

Unsafe typed initialiser. Do not use unless you know the underlying data type the pointer points to conforms to ApplicationProtocol.

Unsafe typed, retaining initialiser. Do not use unless you know the underlying data type the pointer points to conforms to ApplicationProtocol.

Unsafe untyped initialiser. Do not use unless you know the underlying data type the pointer points to conforms to ApplicationProtocol.

Unsafe untyped, retaining initialiser. Do not use unless you know the underlying data type the pointer points to conforms to ApplicationProtocol.

Unsafe untyped initialiser. Do not use unless you know the underlying data type the pointer points to conforms to ApplicationProtocol.

Unsafe untyped, retaining initialiser. Do not use unless you know the underlying data type the pointer points to conforms to ApplicationProtocol.

Unsafe untyped initialiser. Do not use unless you know the underlying data type the pointer points to conforms to ApplicationProtocol.

Unsafe untyped, retaining initialiser. Do not use unless you know the underlying data type the pointer points to conforms to ApplicationProtocol.

Creates a new GtkApplication instance.

When using GtkApplication, it is not necessary to call gtk_init() manually. It is called as soon as the application gets registered as the primary instance.

Concretely, gtk_init() is called in the default handler for the GApplication::startup signal. Therefore, GtkApplication subclasses should chain up in their GApplication::startup handler before using any GTK+ API.

Note that commandline arguments are not passed to gtk_init(). All GTK+ functionality that is available via commandline arguments can also be achieved by setting suitable environment variables such as G_DEBUG, so this should not be a big problem. If you absolutely must support GTK+ commandline arguments, you can explicitly call gtk_init() before creating the application instance.

If non-nil, the application ID must be valid. See g_application_id_is_valid().

If no application ID is given then some features (most notably application uniqueness) will be disabled. A null application ID is only allowed with GTK+ 3.6 or later.

Returns the application singleton instance, creating it if it doesn’t exist yet.

Creates a new #GtkApplication instance.

When using #GtkApplication, it is not necessary to call gtk_init() manually. It is called as soon as the application gets registered as the primary instance.

Concretely, gtk_init() is called in the default handler for the

GApplication::startup signal. Therefore, #GtkApplication subclasses should

chain up in their #GApplication::startup handler before using any GTK+ API.

Note that commandline arguments are not passed to gtk_init(). All GTK+ functionality that is available via commandline arguments can also be achieved by setting suitable environment variables such as G_DEBUG, so this should not be a big problem. If you absolutely must support GTK+ commandline arguments, you can explicitly call gtk_init() before creating the application instance.

If non-%NULL, the application ID must be valid. See g_application_id_is_valid().

If no application ID is given then some features (most notably application uniqueness) will be disabled. A null application ID is only allowed with GTK+ 3.6 or later.

Runs the application. This function is intended to be run from main() and its return value is intended to be returned by main(). Although you are expected to pass the argc , argv parameters from main() to this function, it is possible to pass NULL if argv is not available or commandline handling is not required. Note that on Windows, argc and argv are ignored, and g_win32_get_command_line() is called internally (for proper support of Unicode commandline arguments). GApplication will attempt to parse the commandline arguments. You can add commandline flags to the list of recognised options by way of g_application_add_main_option_entries(). After this, the “handle-local-options” signal is emitted, from which the application can inspect the values of its GOptionEntrys. “handle-local-options” is a good place to handle options such as –version, where an immediate reply from the local process is desired (instead of communicating with an already-running instance). A “handle-local-options” handler can stop further processing by returning a non-negative value, which then becomes the exit status of the process. What happens next depends on the flags: if G_APPLICATION_HANDLES_COMMAND_LINE was specified then the remaining commandline arguments are sent to the primary instance, where a “command-line” signal is emitted. Otherwise, the remaining commandline arguments are assumed to be a list of files. If there are no files listed, the application is activated via the “activate” signal. If there are one or more files, and G_APPLICATION_HANDLES_OPEN was specified then the files are opened via the “open” signal. If you are interested in doing more complicated local handling of the commandline then you should implement your own GApplication subclass and override local_command_line(). In this case, you most likely want to return TRUE from your local_command_line() implementation to suppress the default handling. See gapplication-example-cmdline2.c for an example. If, after the above is done, the use count of the application is zero then the exit status is returned immediately. If the use count is non-zero then the default main context is iterated until the use count falls to zero, at which point 0 is returned. If the G_APPLICATION_IS_SERVICE flag is set, then the service will run for as much as 10 seconds with a use count of zero while waiting for the message that caused the activation to arrive. After that, if the use count falls to zero the application will exit immediately, except in the case that g_application_set_inactivity_timeout() is in use. This function sets the prgname (g_set_prgname()), if not already set, to the basename of argv[0]. Since 2.40, applications that are not explicitly flagged as services or launchers (ie: neither G_APPLICATION_IS_SERVICE or G_APPLICATION_IS_LAUNCHER are given as flags) will check (from the default handler for local_command_line) if “–gapplication-service” was given in the command line. If this flag is present then normal commandline processing is interrupted and the G_APPLICATION_IS_SERVICE flag is set. This provides a “compromise” solution whereby running an application directly from the commandline will invoke it in the normal way (which can be useful for debugging) while still allowing applications to be D-Bus activated in service mode. The D-Bus service file should invoke the executable with “–gapplication-service” as the sole commandline argument. This approach is suitable for use by most graphical applications but should not be used from applications like editors that need precise control over when processes invoked via the commandline will exit and what their exit status will be.

Runs the application. This function is intended to be run from main() and its return value is intended to be returned by main(). Although you are expected to pass the argc , argv parameters from main() to this function, it is possible to pass NULL if argv is not available or commandline handling is not required. Note that on Windows, argc and argv are ignored, and g_win32_get_command_line() is called internally (for proper support of Unicode commandline arguments). GApplication will attempt to parse the commandline arguments. You can add commandline flags to the list of recognised options by way of g_application_add_main_option_entries(). After this, the “handle-local-options” signal is emitted, from which the application can inspect the values of its GOptionEntrys. “handle-local-options” is a good place to handle options such as –version, where an immediate reply from the local process is desired (instead of communicating with an already-running instance). A “handle-local-options” handler can stop further processing by returning a non-negative value, which then becomes the exit status of the process. What happens next depends on the flags: if G_APPLICATION_HANDLES_COMMAND_LINE was specified then the remaining commandline arguments are sent to the primary instance, where a “command-line” signal is emitted. Otherwise, the remaining commandline arguments are assumed to be a list of files. If there are no files listed, the application is activated via the “activate” signal. If there are one or more files, and G_APPLICATION_HANDLES_OPEN was specified then the files are opened via the “open” signal. If you are interested in doing more complicated local handling of the commandline then you should implement your own GApplication subclass and override local_command_line(). In this case, you most likely want to return TRUE from your local_command_line() implementation to suppress the default handling. See gapplication-example-cmdline2.c for an example. If, after the above is done, the use count of the application is zero then the exit status is returned immediately. If the use count is non-zero then the default main context is iterated until the use count falls to zero, at which point 0 is returned. If the G_APPLICATION_IS_SERVICE flag is set, then the service will run for as much as 10 seconds with a use count of zero while waiting for the message that caused the activation to arrive. After that, if the use count falls to zero the application will exit immediately, except in the case that g_application_set_inactivity_timeout() is in use. This function sets the prgname (g_set_prgname()), if not already set, to the basename of argv[0]. Since 2.40, applications that are not explicitly flagged as services or launchers (ie: neither G_APPLICATION_IS_SERVICE or G_APPLICATION_IS_LAUNCHER are given as flags) will check (from the default handler for local_command_line) if “–gapplication-service” was given in the command line. If this flag is present then normal commandline processing is interrupted and the G_APPLICATION_IS_SERVICE flag is set. This provides a “compromise” solution whereby running an application directly from the commandline will invoke it in the normal way (which can be useful for debugging) while still allowing applications to be D-Bus activated in service mode. The D-Bus service file should invoke the executable with “–gapplication-service” as the sole commandline argument. This approach is suitable for use by most graphical applications but should not be used from applications like editors that need precise control over when processes invoked via the commandline will exit and what their exit status will be.

Create and run an application with an optional ID and optional flags. This function is intended to be run from main() and its return value is intended to be returned by main(). Although you are expected to pass the argc , argv parameters from main() to this function, it is possible to pass NULL if argv is not available or commandline handling is not required. Note that on Windows, argc and argv are ignored, and g_win32_get_command_line() is called internally (for proper support of Unicode commandline arguments). GApplication will attempt to parse the commandline arguments. You can add commandline flags to the list of recognised options by way of g_application_add_main_option_entries(). After this, the “handle-local-options” signal is emitted, from which the application can inspect the values of its GOptionEntrys. “handle-local-options” is a good place to handle options such as –version, where an immediate reply from the local process is desired (instead of communicating with an already-running instance). A “handle-local-options” handler can stop further processing by returning a non-negative value, which then becomes the exit status of the process. What happens next depends on the flags: if G_APPLICATION_HANDLES_COMMAND_LINE was specified then the remaining commandline arguments are sent to the primary instance, where a “command-line” signal is emitted. Otherwise, the remaining commandline arguments are assumed to be a list of files. If there are no files listed, the application is activated via the “activate” signal. If there are one or more files, and G_APPLICATION_HANDLES_OPEN was specified then the files are opened via the “open” signal. If you are interested in doing more complicated local handling of the commandline then you should implement your own GApplication subclass and override local_command_line(). In this case, you most likely want to return TRUE from your local_command_line() implementation to suppress the default handling. See gapplication-example-cmdline2.c for an example. If, after the above is done, the use count of the application is zero then the exit status is returned immediately. If the use count is non-zero then the default main context is iterated until the use count falls to zero, at which point 0 is returned. If the G_APPLICATION_IS_SERVICE flag is set, then the service will run for as much as 10 seconds with a use count of zero while waiting for the message that caused the activation to arrive. After that, if the use count falls to zero the application will exit immediately, except in the case that g_application_set_inactivity_timeout() is in use. This function sets the prgname (g_set_prgname()), if not already set, to the basename of argv[0]. Since 2.40, applications that are not explicitly flagged as services or launchers (ie: neither G_APPLICATION_IS_SERVICE or G_APPLICATION_IS_LAUNCHER are given as flags) will check (from the default handler for local_command_line) if “–gapplication-service” was given in the command line. If this flag is present then normal commandline processing is interrupted and the G_APPLICATION_IS_SERVICE flag is set. This provides a “compromise” solution whereby running an application directly from the commandline will invoke it in the normal way (which can be useful for debugging) while still allowing applications to be D-Bus activated in service mode. The D-Bus service file should invoke the executable with “–gapplication-service” as the sole commandline argument. This approach is suitable for use by most graphical applications but should not be used from applications like editors that need precise control over when processes invoked via the commandline will exit and what their exit status will be.

Create and run an application with an optional ID and optional flags. This function is intended to be run from main() and its return value is intended to be returned by main(). Although you are expected to pass the argc , argv parameters from main() to this function, it is possible to pass NULL if argv is not available or commandline handling is not required. Note that on Windows, argc and argv are ignored, and g_win32_get_command_line() is called internally (for proper support of Unicode commandline arguments). GApplication will attempt to parse the commandline arguments. You can add commandline flags to the list of recognised options by way of g_application_add_main_option_entries(). After this, the “handle-local-options” signal is emitted, from which the application can inspect the values of its GOptionEntrys. “handle-local-options” is a good place to handle options such as –version, where an immediate reply from the local process is desired (instead of communicating with an already-running instance). A “handle-local-options” handler can stop further processing by returning a non-negative value, which then becomes the exit status of the process. What happens next depends on the flags: if G_APPLICATION_HANDLES_COMMAND_LINE was specified then the remaining commandline arguments are sent to the primary instance, where a “command-line” signal is emitted. Otherwise, the remaining commandline arguments are assumed to be a list of files. If there are no files listed, the application is activated via the “activate” signal. If there are one or more files, and G_APPLICATION_HANDLES_OPEN was specified then the files are opened via the “open” signal. If you are interested in doing more complicated local handling of the commandline then you should implement your own GApplication subclass and override local_command_line(). In this case, you most likely want to return TRUE from your local_command_line() implementation to suppress the default handling. See gapplication-example-cmdline2.c for an example. If, after the above is done, the use count of the application is zero then the exit status is returned immediately. If the use count is non-zero then the default main context is iterated until the use count falls to zero, at which point 0 is returned. If the G_APPLICATION_IS_SERVICE flag is set, then the service will run for as much as 10 seconds with a use count of zero while waiting for the message that caused the activation to arrive. After that, if the use count falls to zero the application will exit immediately, except in the case that g_application_set_inactivity_timeout() is in use. This function sets the prgname (g_set_prgname()), if not already set, to the basename of argv[0]. Since 2.40, applications that are not explicitly flagged as services or launchers (ie: neither G_APPLICATION_IS_SERVICE or G_APPLICATION_IS_LAUNCHER are given as flags) will check (from the default handler for local_command_line) if “–gapplication-service” was given in the command line. If this flag is present then normal commandline processing is interrupted and the G_APPLICATION_IS_SERVICE flag is set. This provides a “compromise” solution whereby running an application directly from the commandline will invoke it in the normal way (which can be useful for debugging) while still allowing applications to be D-Bus activated in service mode. The D-Bus service file should invoke the executable with “–gapplication-service” as the sole commandline argument. This approach is suitable for use by most graphical applications but should not be used from applications like editors that need precise control over when processes invoked via the commandline will exit and what their exit status will be.