In many situations it is desirable and necessary to have a way to refer to all nodes and/or edges that fulfill certain conditions. Things that should be filterable:
Node Types
Edge Types (possibly with a defined start node, or matching source and/or target nodes of the matching edges
Node attributes (whether they exist, also whether the values fulfill conditions)
Edge attributes
? Maybe node data also down the line
The exact capabilities and implementation of filters will certainly evolve and change over time. Eventually this filter data structure should be general enough to be usable in a variety of situations:
Selecting what kinds of nodes to expand
Selecting what nodes to apply simulation forces to
Hiding/showing nodes
As an input to some types of operators (possibly)
I also am partial to the idea that filters should be a node type. This would play nicely with forces (which would also be nodes) and operators. I don't have a clear idea of how this would mesh with expanding and collapsing contexts, though. For that use-case it could be better to have the Filter as a normal struct and for the node type to be a wrapper around it.
In many situations it is desirable and necessary to have a way to refer to all nodes and/or edges that fulfill certain conditions. Things that should be filterable:
The exact capabilities and implementation of filters will certainly evolve and change over time. Eventually this filter data structure should be general enough to be usable in a variety of situations:
I also am partial to the idea that filters should be a node type. This would play nicely with forces (which would also be nodes) and operators. I don't have a clear idea of how this would mesh with expanding and collapsing contexts, though. For that use-case it could be better to have the Filter as a normal struct and for the node type to be a wrapper around it.