Layouts#
Native layout engines within Graphistry.
We recommend using the various plugins for additional layouts, such as for tree and hierarchical data diagramming.
Contents:
- Circle Layout
- ForceAtlas2 Layout
- Group-in-a-Box Layout
- Modularity Weighted Layout
- Ring Layouts: Categorical, Continuous, Time
- Sugiyama Layout
- Utils
- Submodules
- graphistry.layout.utils.dummyVertex module
- graphistry.layout.utils.geometry module
- graphistry.layout.utils.layer module
- graphistry.layout.utils.layoutVertex module
- graphistry.layout.utils.poset module
- graphistry.layout.utils.rectangle module
- graphistry.layout.utils.routing module
- Module contents
- graphistry.layout.graph.edge module
- graphistry.layout.graph.edgeBase module
- graphistry.layout.graph.graph module
- graphistry.layout.graph.graphBase module
- graphistry.layout.graph.vertex module
- graphistry.layout.graph.vertexBase module
- Module contents
Layout plugins: igraph, graphviz, and more#
Several plugins provide a large variety of additional layouts:
LayoutsMixin#
Base class for protocol classes.
Protocol classes are defined as:
class Proto(Protocol):
def meth(self) -> int:
...
Such classes are primarily used with static type checkers that recognize structural subtyping (static duck-typing).
For example:
class C:
def meth(self) -> int:
return 0
def func(x: Proto) -> int:
return x.meth()
func(C()) # Passes static type check
See PEP 544 for details. Protocol classes decorated with @typing.runtime_checkable act as simple-minded runtime protocols that check only the presence of given attributes, ignoring their type signatures. Protocol classes can be generic, they are defined as:
class GenProto[T](Protocol):
def meth(self) -> T:
...