Package org.gnome.gio

Interface Application.HandleLocalOptionsCallback

All Superinterfaces:

FunctionPointer

Enclosing class:

Application

Functional Interface:

This is a functional interface and can therefore be used as the assignment target for a lambda expression or method reference.

@FunctionalInterface
public static interface Application.HandleLocalOptionsCallback
extends FunctionPointer

Functional interface declaration of the HandleLocalOptionsCallback callback.

See Also:

• run(org.gnome.glib.VariantDict)

Method Summary

Modifier and Type	Method	Description
int	run(@Nullable VariantDict options)	The ::handle-local-options signal is emitted on the local instance after the parsing of the commandline options has occurred.
default MemorySegment	toCallback(Arena arena)	Creates a native function pointer to the upcall(java.lang.foreign.MemorySegment, java.lang.foreign.MemorySegment) method.
default int	upcall(MemorySegment sourceApplication, MemorySegment options)	The upcall method is called from native code.

Method Details

run

int run(@Nullable VariantDict options)

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

Since:

2.40

upcall

default int upcall(MemorySegment sourceApplication,
 MemorySegment options)

The upcall method is called from native code. The parameters are marshaled and run(org.gnome.glib.VariantDict) is executed.

toCallback

default MemorySegment toCallback(Arena arena)

Creates a native function pointer to the upcall(java.lang.foreign.MemorySegment, java.lang.foreign.MemorySegment) method.

Specified by:

toCallback in interface FunctionPointer

Parameters:

arena - the arena in which the function pointer is allocated

Returns:

the native function pointer