Package org.gnome.gio

Interface ActionGroup

All Superinterfaces:
Proxy
All Known Subinterfaces:
RemoteActionGroup
All Known Implementing Classes:
ActionGroup.ActionGroupImpl, Application, Application, Application, ApplicationWindow, ApplicationWindow, DBusActionGroup, RemoteActionGroup.RemoteActionGroupImpl, SimpleActionGroup

@Generated("io.github.jwharm.JavaGI") public interface ActionGroup extends Proxy
GActionGroup represents a group of actions.

Actions can be used to expose functionality in a structured way, either from one part of a program to another, or to the outside world. Action groups are often used together with a Gio.MenuModel that provides additional representation data for displaying the actions to the user, e.g. in a menu.

The main way to interact with the actions in a GActionGroup is to activate them with activateAction(java.lang.String, org.gnome.glib.Variant). Activating an action may require a GLib.Variant parameter. The required type of the parameter can be inquired with getActionParameterType(java.lang.String). Actions may be disabled, see getActionEnabled(java.lang.String). Activating a disabled action has no effect.

Actions may optionally have a state in the form of a GLib.Variant. The current state of an action can be inquired with getActionState(java.lang.String). Activating a stateful action may change its state, but it is also possible to set the state by calling changeActionState(java.lang.String, org.gnome.glib.Variant).

As typical example, consider a text editing application which has an option to change the current font to ‘bold’. A good way to represent this would be a stateful action, with a boolean state. Activating the action would toggle the state.

Each action in the group has a unique name (which is a string). All method calls, except listActions() take the name of an action as an argument.

The GActionGroup API is meant to be the ‘public’ API to the action group. The calls here are exactly the interaction that ‘external forces’ (eg: UI, incoming D-Bus messages, etc.) are supposed to have with actions. ‘Internal’ APIs (ie: ones meant only to be accessed by the action group implementation) are found on subclasses. This is why you will find – for example – getActionEnabled(java.lang.String) but not an equivalent set_action_enabled() method.

Signals are emitted on the action group in response to state changes on individual actions.

Implementations of GActionGroup should provide implementations for the virtual functions listActions() and queryAction(java.lang.String, io.github.jwharm.javagi.base.Out<java.lang.Boolean>, io.github.jwharm.javagi.base.Out<org.gnome.glib.VariantType>, io.github.jwharm.javagi.base.Out<org.gnome.glib.VariantType>, io.github.jwharm.javagi.base.Out<org.gnome.glib.Variant>, io.github.jwharm.javagi.base.Out<org.gnome.glib.Variant>). The other virtual functions should not be implemented — their ‘wrappers’ are actually implemented with calls to queryAction(java.lang.String, io.github.jwharm.javagi.base.Out<java.lang.Boolean>, io.github.jwharm.javagi.base.Out<org.gnome.glib.VariantType>, io.github.jwharm.javagi.base.Out<org.gnome.glib.VariantType>, io.github.jwharm.javagi.base.Out<org.gnome.glib.Variant>, io.github.jwharm.javagi.base.Out<org.gnome.glib.Variant>).