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 Application.commandLineGetOptionsDict. 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 Application.activate. One or
more arguments results in a call to Application.open.
If you want to handle the local commandline arguments for yourself
by converting them to calls to Application.open or
Action.groupActivateAction then you must be sure to register
the application first. You should probably not call
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.
an exit code. If you have handled your options and want
to exit the process, return a non-negative option, 0 for success,
and a positive value for failure. To continue, return -1 to let
the default option processing continue.
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 Application.addMainOptionEntries and Application.addOptionGroup.
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 Application.commandLineGetOptionsDict. 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 Application.activate. One or more arguments results in a call to Application.open.
If you want to handle the local commandline arguments for yourself by converting them to calls to Application.open or Action.groupActivateAction then you must be sure to register the application first. You should probably not call 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.