When using gtk.Application, 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
startup signal. Therefore, gtk.Application subclasses should
chain up in their 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 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 gtk.Application instance.
When using gtk.Application, 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 startup signal. Therefore, gtk.Application subclasses should chain up in their 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 Application.idIsValid.
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.