gi-gio-2.0.38: Gio bindings

Copyright | Will Thompson and Iñaki García Etxebarria
License | LGPL-2.1
Maintainer | Iñaki García Etxebarria
Safe Haskell | None
Language | Haskell2010

GI.Gio.Objects.MenuModel

Contents

- Exported types
- Methods
  - getItemAttributeValue
  - getItemLink
  - getNItems
  - isMutable
  - itemsChanged
  - iterateItemAttributes
  - iterateItemLinks
- Signals
  - itemsChanged

Description

`GMenuModel` represents the contents of a menu — an ordered list of menu items. The items are associated with actions, which can be activated through them. Items can be grouped in sections, and may have submenus associated with them. Both items and sections usually have some representation data, such as labels or icons. The type of the associated action (ie whether it is stateful, and what kind of state it has) can influence the representation of the item.

The conceptual model of menus in `GMenuModel` is hierarchical: sections and submenus are again represented by `GMenuModel`s. Menus themselves do not define their own roles. Rather, the role of a particular `GMenuModel` is defined by the item that references it (or, in the case of the ‘root’ menu, is defined by the context in which it is used).

As an example, consider the visible portions of this menu:

## An example menu

While this kind of deeply nested menu is no longer considered good UI practice, it serves as a good example of the concepts in `GMenuModel`. There are 8 ‘menus’ visible in the screenshot: one menubar, two submenus and 5 sections:

- the toplevel menubar (containing 4 items)
- the View submenu (containing 3 sections)
- the first section of the View submenu (containing 2 items)
- the second section of the View submenu (containing 1 item)
- the final section of the View submenu (containing 1 item)
- the Highlight Mode submenu (containing 2 sections)
- the Sources section (containing 2 items)
- the Markup section (containing 2 items)

The example illustrates the conceptual connection between these 8 menus. Each large block in the figure represents a menu and the smaller blocks within the large block represent items in that menu. Some items contain references to other menus.

## A menu example

<picture> <source srcset="menu-model-dark.svg" media="(prefers-color-scheme: dark)"> <img src="menu-model-light.svg" alt="menu model"> </picture>

Notice that the separators visible in the example appear nowhere in the menu model. This is because separators are not explicitly represented in the menu model. Instead, a separator is inserted between any two non-empty sections of a menu. Section items can have labels just like any other item. In that case, a display system may show a section header instead of a separator.

The motivation for this abstract model of application controls is that modern user interfaces tend to make these controls available outside the application. Examples include global menus, jumplists, dash boards, etc. To support such uses, it is necessary to ‘export’ information about actions and their representation in menus, which is exactly what the action group exporter and the menu model exporter do for `ActionGroup` and `MenuModel`. The client-side counterparts to make use of the exported information are `DBusActionGroup` and `DBusMenuModel`.

The API of `GMenuModel` is very generic, with iterators for the attributes and links of an item, see `menuModelIterateItemAttributes` and `menuModelIterateItemLinks`. The ‘standard’ attributes and link types have predefined names: `G_MENU_ATTRIBUTE_LABEL`, `G_MENU_ATTRIBUTE_ACTION`, `G_MENU_ATTRIBUTE_TARGET`, `G_MENU_LINK_SECTION` and `G_MENU_LINK_SUBMENU`.

Items in a `GMenuModel` represent active controls if they refer to an action that can get activated when the user interacts with the menu item. The reference to the action is encoded by the string ID in the `G_MENU_ATTRIBUTE_ACTION` attribute. An action ID uniquely identifies an action in an action group. Which action group(s) provide actions depends on the context in which the menu model is used. E.g. when the model is exported as the application menu of a `GtkApplication`, actions can be application-wide or window-specific (and thus come from two different action groups). By convention, the application-wide actions have names that start with `app.`, while the names of window-specific actions start with `win.`.

While a wide variety of stateful actions is possible, the following is the minimum that is expected to be supported by all users of exported menu information: * an action with no parameter type and no state * an action with no parameter type and boolean state * an action with string parameter type and string state

## Stateless

A stateless action typically corresponds to an ordinary menu item.

Selecting such a menu item will activate the action (with no parameter).

## Boolean State

An action with a boolean state will most typically be used with a ‘toggle’ or ‘switch’ menu item. The state can be set directly, but activating the action (with no parameter) results in the state being toggled.

Selecting a toggle menu item will activate the action. The menu item should be rendered as ‘checked’ when the state is true.

## String Parameter and State

Actions with string parameters and state will most typically be used to represent an enumerated choice over the items available for a group of radio menu items. Activating the action with a string parameter is equivalent to setting that parameter as the state.

Radio menu items, in addition to being associated with the action, will have a target value. Selecting that menu item will result in activation of the action with the target value as the parameter. The menu item should be rendered as ‘selected’ when the state of the action is equal to the target value of the menu item.

Since: 2.32

Synopsis

- newtype MenuModel = MenuModel (ManagedPtr MenuModel)
- class (GObject o, IsDescendantOf MenuModel o) => IsMenuModel o
- toMenuModel :: (MonadIO m, IsMenuModel o) => o -> m MenuModel
- menuModelGetItemAttributeValue :: (HasCallStack, MonadIO m, IsMenuModel a) => a -> Int32 -> Text -> Maybe VariantType -> m (Maybe GVariant)
- menuModelGetItemLink :: (HasCallStack, MonadIO m, IsMenuModel a) => a -> Int32 -> Text -> m (Maybe MenuModel)
- menuModelGetNItems :: (HasCallStack, MonadIO m, IsMenuModel a) => a -> m Int32
- menuModelIsMutable :: (HasCallStack, MonadIO m, IsMenuModel a) => a -> m Bool
- menuModelItemsChanged :: (HasCallStack, MonadIO m, IsMenuModel a) => a -> Int32 -> Int32 -> Int32 -> m ()
- menuModelIterateItemAttributes :: (HasCallStack, MonadIO m, IsMenuModel a) => a -> Int32 -> m MenuAttributeIter
- menuModelIterateItemLinks :: (HasCallStack, MonadIO m, IsMenuModel a) => a -> Int32 -> m MenuLinkIter
- type MenuModelItemsChangedCallback = Int32 -> Int32 -> Int32 -> IO ()
- afterMenuModelItemsChanged :: (IsMenuModel a, MonadIO m) => a -> ((?self :: a) => MenuModelItemsChangedCallback) -> m SignalHandlerId
- onMenuModelItemsChanged :: (IsMenuModel a, MonadIO m) => a -> ((?self :: a) => MenuModelItemsChangedCallback) -> m SignalHandlerId

# Exported types

newtype MenuModel Source #

Memory-managed wrapper type.

Constructors

MenuModel (ManagedPtr MenuModel) |

#### Instances

Instances details

Eq MenuModel Source # |
Instance details Defined in GI.Gio.Objects.MenuModel Methods (==) :: MenuModel -> MenuModel -> Bool Source # (/=) :: MenuModel -> MenuModel -> Bool Source #
GObject MenuModel Source # |
Instance details Defined in GI.Gio.Objects.MenuModel
ManagedPtrNewtype MenuModel Source # |
Instance details Defined in GI.Gio.Objects.MenuModel Methods toManagedPtr :: MenuModel -> ManagedPtr MenuModel Source #
TypedObject MenuModel Source # |
Instance details Defined in GI.Gio.Objects.MenuModel Methods glibType :: IO GType Source #
HasParentTypes MenuModel Source # |
Instance details Defined in GI.Gio.Objects.MenuModel
IsGValue (Maybe MenuModel) Source # | Convert `MenuModel` to and from `GValue`. See `toGValue` and `fromGValue`.
Instance details Defined in GI.Gio.Objects.MenuModel Methods gvalueGType_ :: IO GType Source # gvalueSet_ :: Ptr GValue -> Maybe MenuModel -> IO () Source # gvalueGet_ :: Ptr GValue -> IO (Maybe MenuModel) Source #
type ParentTypes MenuModel Source # |
Instance details Defined in GI.Gio.Objects.MenuModel type ParentTypes MenuModel = '[Object]

class (GObject o, IsDescendantOf MenuModel o) => IsMenuModel o Source #

Type class for types which can be safely cast to `MenuModel`, for instance with `toMenuModel`.

#### Instances

Instances details

(GObject o, IsDescendantOf MenuModel o) => IsMenuModel o Source # |
Instance details Defined in GI.Gio.Objects.MenuModel

toMenuModel :: (MonadIO m, IsMenuModel o) => o -> m MenuModel Source #

Cast to `MenuModel`, for types for which this is known to be safe. For general casts, use `castTo`.

# Methods

### Click to display all available methods, including inherited ones

Expand

#### Methods

bindProperty, bindPropertyFull, forceFloating, freezeNotify, getv, isFloating, isMutable, itemsChanged, iterateItemAttributes, iterateItemLinks, notify, notifyByPspec, ref, refSink, runDispose, stealData, stealQdata, thawNotify, unref, watchClosure.

#### Getters

getData, getItemAttributeValue, getItemLink, getNItems, getProperty, getQdata.

#### Setters

setData, setDataFull, setProperty.

## getItemAttributeValue

menuModelGetItemAttributeValue Source #

Arguments

:: (HasCallStack, MonadIO m, IsMenuModel a) |
=> a | `model`: a `MenuModel`
-> Int32 | `itemIndex`: the index of the item
-> Text | `attribute`: the attribute to query
-> Maybe VariantType | `expectedType`: the expected type of the attribute, or `Nothing`
-> m (Maybe GVariant) | Returns: the value of the attribute

Queries the item at position `itemIndex` in `model` for the attribute specified by `attribute`.

If `expectedType` is non-`Nothing` then it specifies the expected type of the attribute. If it is `Nothing` then any type will be accepted.

If the attribute exists and matches `expectedType` (or if the expected type is unspecified) then the value is returned.

If the attribute does not exist, or does not match the expected type then `Nothing` is returned.

Since: 2.32

## getItemLink

menuModelGetItemLink Source #

Arguments

:: (HasCallStack, MonadIO m, IsMenuModel a) |
=> a | `model`: a `MenuModel`
-> Int32 | `itemIndex`: the index of the item
-> Text | `link`: the link to query
-> m (Maybe MenuModel) | Returns: the linked `MenuModel`, or `Nothing`

Queries the item at position `itemIndex` in `model` for the link specified by `link`.

If the link exists, the linked `MenuModel` is returned. If the link does not exist, `Nothing` is returned.

Since: 2.32

## getNItems

menuModelGetNItems Source #

Arguments

:: (HasCallStack, MonadIO m, IsMenuModel a) |
=> a | `model`: a `MenuModel`
-> m Int32 | Returns: the number of items

Query the number of items in `model`.

Since: 2.32

## isMutable

menuModelIsMutable Source #

Arguments

:: (HasCallStack, MonadIO m, IsMenuModel a) |
=> a | `model`: a `MenuModel`
-> m Bool | Returns: `True` if the model is mutable (ie: "items-changed" may be emitted).

Queries if `model` is mutable.

An immutable `MenuModel` will never emit the MenuModel::itemsChanged signal. Consumers of the model may make optimisations accordingly.

Since: 2.32

## itemsChanged

menuModelItemsChanged Source #

Arguments

:: (HasCallStack, MonadIO m, IsMenuModel a) |
=> a | `model`: a `MenuModel`
-> Int32 | `position`: the position of the change
-> Int32 | `removed`: the number of items removed
-> Int32 | `added`: the number of items added
-> m () |

Requests emission of the MenuModel::itemsChanged signal on `model`.

This function should never be called except by `MenuModel` subclasses. Any other calls to this function will very likely lead to a violation of the interface of the model.

The implementation should update its internal representation of the menu before emitting the signal. The implementation should further expect to receive queries about the new state of the menu (and particularly added menu items) while signal handlers are running.

The implementation must dispatch this call directly from a mainloop entry and not in response to calls -- particularly those from the `MenuModel` API. Said another way: the menu must not change while user code is running without returning to the mainloop.

Since: 2.32

## iterateItemAttributes

menuModelIterateItemAttributes Source #

Arguments

:: (HasCallStack, MonadIO m, IsMenuModel a) |
=> a | `model`: a `MenuModel`
-> Int32 | `itemIndex`: the index of the item
-> m MenuAttributeIter | Returns: a new `MenuAttributeIter`

Creates a `MenuAttributeIter` to iterate over the attributes of the item at position `itemIndex` in `model`.

You must free the iterator with `objectUnref` when you are done.

Since: 2.32

## iterateItemLinks

menuModelIterateItemLinks Source #

Arguments

:: (HasCallStack, MonadIO m, IsMenuModel a) |
=> a | `model`: a `MenuModel`
-> Int32 | `itemIndex`: the index of the item
-> m MenuLinkIter | Returns: a new `MenuLinkIter`

Creates a `MenuLinkIter` to iterate over the links of the item at position `itemIndex` in `model`.

You must free the iterator with `objectUnref` when you are done.

Since: 2.32

# Signals

## itemsChanged

type MenuModelItemsChangedCallback Source #

Arguments

= Int32 | `position`: the position of the change
-> Int32 | `removed`: the number of items removed
-> Int32 | `added`: the number of items added
-> IO () |

Emitted when a change has occurred to the menu.

The only changes that can occur to a menu is that items are removed or added. Items may not change (except by being removed and added back in the same location). This signal is capable of describing both of those changes (at the same time).

The signal means that starting at the index `position`, `removed` items were removed and `added` items were added in their place. If `removed` is zero then only items were added. If `added` is zero then only items were removed.

As an example, if the menu contains items a, b, c, d (in that order) and the signal (2, 1, 3) occurs then the new composition of the menu will be a, b, _, _, _, d (with each _ representing some new item).

Signal handlers may query the model (particularly the added items) and expect to see the results of the modification that is being reported. The signal is emitted after the modification.

afterMenuModelItemsChanged :: (IsMenuModel a, MonadIO m) => a -> ((?self :: a) => MenuModelItemsChangedCallback) -> m SignalHandlerId Source #

Connect a signal handler for the itemsChanged signal, to be run after the default handler. When overloading is enabled, this is equivalent to

    after menuModel #itemsChanged callback

By default the object invoking the signal is not passed to the callback. If you need to access it, you can use the implit `?self` parameter. Note that this requires activating the `ImplicitParams` GHC extension.

onMenuModelItemsChanged :: (IsMenuModel a, MonadIO m) => a -> ((?self :: a) => MenuModelItemsChangedCallback) -> m SignalHandlerId Source #

Connect a signal handler for the itemsChanged signal, to be run before the default handler. When overloading is enabled, this is equivalent to

    on menuModel #itemsChanged callback