The ::handle-local-options signal is emitted on the local instance
after the parsing of the commandline options has occurred.
You can add options to be recognised during commandline option
parsing using g_application_add_main_option_entries() and
g_application_add_option_group().
Signal handlers can inspect @options (along with values pointed to
from the @arg_data of an installed #GOptionEntrys) in order to
decide to perform certain actions, including direct local handling
(which may be useful for options like --version).
In the event that the application is marked
%G_APPLICATION_HANDLES_COMMAND_LINE the "normal processing" will
send the @options dictionary to the primary instance where it can be
read with g_application_command_line_get_options_dict(). The signal
handler can modify the dictionary before returning, and the
modified dictionary will be sent.
In the event that %G_APPLICATION_HANDLES_COMMAND_LINE is not set,
"normal processing" will treat the remaining uncollected command
line arguments as filenames or URIs. If there are no arguments,
the application is activated by g_application_activate(). One or
more arguments results in a call to g_application_open().
If you want to handle the local commandline arguments for yourself
by converting them to calls to g_application_open() or
g_action_group_activate_action() then you must be sure to register
the application first. You should probably not call
g_application_activate() for yourself, however: just return -1 and
allow the default handler to do it for you. This will ensure that
the --gapplication-service switch works properly (i.e. no activation
in that case).
Note that this signal is emitted from the default implementation of
local_command_line(). If you override that function and don't
chain up then this signal will never be emitted.
You can override local_command_line() if you need more powerful
capabilities than what is provided here, but this should not
normally be required.
The ::handle-local-options signal is emitted on the local instance after the parsing of the commandline options has occurred.
You can add options to be recognised during commandline option parsing using g_application_add_main_option_entries() and g_application_add_option_group().
Signal handlers can inspect @options (along with values pointed to from the @arg_data of an installed #GOptionEntrys) in order to decide to perform certain actions, including direct local handling (which may be useful for options like --version).
In the event that the application is marked %G_APPLICATION_HANDLES_COMMAND_LINE the "normal processing" will send the @options dictionary to the primary instance where it can be read with g_application_command_line_get_options_dict(). The signal handler can modify the dictionary before returning, and the modified dictionary will be sent.
In the event that %G_APPLICATION_HANDLES_COMMAND_LINE is not set, "normal processing" will treat the remaining uncollected command line arguments as filenames or URIs. If there are no arguments, the application is activated by g_application_activate(). One or more arguments results in a call to g_application_open().
If you want to handle the local commandline arguments for yourself by converting them to calls to g_application_open() or g_action_group_activate_action() then you must be sure to register the application first. You should probably not call g_application_activate() for yourself, however: just return -1 and allow the default handler to do it for you. This will ensure that the --gapplication-service switch works properly (i.e. no activation in that case).
Note that this signal is emitted from the default implementation of local_command_line(). If you override that function and don't chain up then this signal will never be emitted.
You can override local_command_line() if you need more powerful capabilities than what is provided here, but this should not normally be required.