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.
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.