Hoogle Search
Within LTS Haskell 24.32 (ghc-9.10.3)
Note that Stackage only displays results for the latest LTS and Nightly snapshot. Learn more.
fileEnumeratorIsClosed :: (HasCallStack, MonadIO m, IsFileEnumerator a) => a -> m Boolgi-gio GI.Gio.Objects.FileEnumerator Checks if the file enumerator has been closed.
-
gi-gio GI.Gio.Objects.FileEnumerator This is a version of fileEnumeratorNextFile that's easier to use correctly from C programs. With fileEnumeratorNextFile, the gboolean return value signifies "end of iteration or error", which requires allocation of a temporary GError. In contrast, with this function, a False return from fileEnumeratorIterate *always* means "error". End of iteration is signaled by outInfo or outChild being Nothing. Another crucial difference is that the references for outInfo and outChild are owned by direnum (they are cached as hidden properties). You must not unref them in your own code. This makes memory management significantly easier for C code in combination with loops. Finally, this function optionally allows retrieving a File as well. You must specify at least one of outInfo or outChild. The code pattern for correctly using fileEnumeratorIterate from C is:
direnum = g_file_enumerate_children (file, ...); while (TRUE) { GFileInfo *info; if (!g_file_enumerator_iterate (direnum, &info, NULL, cancellable, error)) goto out; if (!info) break; ... do stuff with "info"; do not unref it! ... } out: g_object_unref (direnum); // Note: frees the last @infoSince: 2.44 -
gi-gio GI.Gio.Objects.FileEnumerator Returns information for the next file in the enumerated object. Will block until the information is available. The FileInfo returned from this function will contain attributes that match the attribute string that was passed when the FileEnumerator was created. See the documentation of FileEnumerator for information about the order of returned files. On error, returns Nothing and sets error to the error. If the enumerator is at the end, Nothing will be returned and error will be unset.
-
gi-gio GI.Gio.Objects.FileEnumerator Request information for a number of files from the enumerator asynchronously. When all I/O for the operation is finished the callback will be called with the requested information. See the documentation of FileEnumerator for information about the order of returned files. Once the end of the enumerator is reached, or if an error occurs, the callback will be called with an empty list. In this case, the previous call to fileEnumeratorNextFilesAsync will typically have returned fewer than numFiles items. If a request is cancelled the callback will be called with IOErrorEnumCancelled. This leads to the following pseudo-code usage:
g_autoptr(GFile) dir = get_directory (); g_autoptr(GFileEnumerator) enumerator = NULL; g_autolist(GFileInfo) files = NULL; g_autoptr(GError) local_error = NULL; enumerator = yield g_file_enumerate_children_async (dir, G_FILE_ATTRIBUTE_STANDARD_NAME "," G_FILE_ATTRIBUTE_STANDARD_TYPE, G_FILE_QUERY_INFO_NONE, G_PRIORITY_DEFAULT, cancellable, …, &local_error); if (enumerator == NULL) g_error ("Error enumerating: %s", local_error->message); // Loop until no files are returned, either because the end of the enumerator // has been reached, or an error was returned. do { files = yield g_file_enumerator_next_files_async (enumerator, 5, // number of files to request G_PRIORITY_DEFAULT, cancellable, …, &local_error); // Process the returned files, but don’t assume that exactly 5 were returned. for (GList *l = files; l != NULL; l = l->next) { GFileInfo *info = l->data; handle_file_info (info); } } while (files != NULL); if (local_error != NULL && !g_error_matches (local_error, G_IO_ERROR, G_IO_ERROR_CANCELLED)) g_error ("Error while enumerating: %s", local_error->message);During an async request no other sync and async calls are allowed, and will result in IOErrorEnumPending errors. Any outstanding I/O request with higher priority (lower numerical value) will be executed before an outstanding request with lower priority. Default priority is PRIORITY_DEFAULT. -
gi-gio GI.Gio.Objects.FileEnumerator Finishes the asynchronous operation started with fileEnumeratorNextFilesAsync.
fileEnumeratorSetPending :: (HasCallStack, MonadIO m, IsFileEnumerator a) => a -> Bool -> m ()gi-gio GI.Gio.Objects.FileEnumerator Sets the file enumerator as having pending operations.
toFileEnumerator :: (MonadIO m, IsFileEnumerator o) => o -> m FileEnumeratorgi-gio GI.Gio.Objects.FileEnumerator Cast to FileEnumerator, for types for which this is known to be safe. For general casts, use castTo.
module GI.Gio.Objects.
MenuModel 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 GMenuModels. 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
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)
A menu example
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 stateStateless
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.32class (GObject o, IsDescendantOf MenuModel o) =>
IsMenuModel ogi-gio GI.Gio.Objects.MenuModel Type class for types which can be safely cast to MenuModel, for instance with toMenuModel.
-
gi-gio GI.Gio.Objects.MenuModel Memory-managed wrapper type.