Package: gtk
Class gtk-tree-model-filter
SuperclassesDocumented Subclasses
None
Direct SlotsDetails A gtk-tree-model-filter object is a tree model which wraps another
tree model. The gtk-tree-model-filter object can do the following things:
When using the gtk-tree-model-filter object, it is important to realize that the gtk-tree-model-filter object maintains an internal cache of all nodes which are visible in its clients. The cache is likely to be a subtree of the tree exposed by the child model. The gtk-tree-model-filter object will not cache the entire child model when unnecessary to not compromise the caching mechanism that is exposed by the reference counting scheme. If the child model implements reference counting, unnecessary signals may not be emitted because of reference counting rule 3, see the gtk-tree-model documentation. Note that e.g. the gtk-tree-store object does not implement reference counting and will always emit all signals, even when the receiving node is not visible. Because of this, limitations for possible visible functions do apply. In general, visible functions should only use data or properties from the node for which the visibility state must be determined, its siblings or its parents. Usually, having a dependency on the state of any child node is not possible, unless references are taken on these explicitly. When no such reference exists, no signals may be received for these child nodes. See reference couting rule number 3 in the gtk-tree-model documentation. Determining the visibility state of a given node based on the state of its child nodes is a frequently occurring use case. Therefore, the gtk-tree-model-filter object explicitly supports this. For example, when a node does not have any children, you might not want the node to be visible. As soon as the first row is added to the node's child level, or the last row removed, the node's visibility should be updated. This introduces a dependency from the node on its child nodes. In order to accommodate this, the gtk-tree-model-filter object must make sure the necesary signals are received from the child model. This is achieved by building, for all nodes which are exposed as visible nodes to the gtk-tree-model-filter objects clients, the child level (if any) and take a reference on the first node in this level. Furthermore, for every "row-inserted", "row-changed" or "row-deleted" signal, also these which were not handled because the node was not cached, the gtk-tree-model-filter oject will check if the visibility state of any parent node has changed. Beware, however, that this explicit support is limited to these two cases. For example, if you want a node to be visible only if two nodes in a child's child level (2 levels deeper) are visible, you are on your own. In this case, either rely on the gtk-tree-store object to emit all signals because it does not implement reference counting, or for models that do implement reference counting, obtain references on these child levels yourself. | Slot Access FunctionsInherited Slot Access FunctionsSee also |
2021-3-7