A concept/idea stage atm, but seems simple enough and nice.
The builtin style might want to have a sigil. The default possibly too.
The core idea is that everything that is not annotated uses the
"default" style, which is user-tweakable and defaults to the "builtin"
style, which makes sure everything gets drawn in some sane way.
Implementation-wise, a first annotator would lay out the vertices and
shortcut them possibly, second one would lay out the
unpositioned-but-shown vertices (in a similar way to the
random_positioner), third would process the styling graph and annotate
with styling directives. The actual visualisation would then just read
the annotations and topology¹ and draw that into the QGraphicsScene.
¹ We might need to devise a different representation to make sure thaat
the shortcuts work reasonably.
For a very broad overview, something akin to:
style default
hide
style important
show
pen color red
could be used.
The styling should possibly be in opposite order: object property
params. This way, we can quickly ignore the irrelevant properties (like
line width for vertices)
An extreme but probably workable idea would be to reuse a TopologyV3.
While the families and addresses make zero sense, it could represent the
reduced graph. However, we would need some way of mapping the new
vertices/edges to the old ones (for Dijkstra &c.), so it is probably
just better to create an Annotator-driven "overlay" in the existing
AnnotatedTopology (reuse a subset of VertexIDs, maybe create own Edges.
Those objects can exist without a TopologyV3, so it is fine. Also, at
that point we do not need to use too-reasonable objects in the
Annotations.)
Regarding the "icon router bleg.svg": We will probably want to only
allow files from assets in the beginning, so that the visualisation
files are portable without any restrictions. In future, we could have a
visualisation-relative resolution and/or directives to add other paths.
(maybe with prefixes, Pelican style)
The styles should possibly be top-level directives, not l2, so that they
are reusable between presets (in the same file)
This script serves as a simple demonstration of how to use birdvisu.
Over time, it should become shorter, as more of its features are
integrated into birdvisu itself, until at last it becomes only a very
thin wrapper.
The functionality will probably be incorporated into some core /
orchestrator birdvisu module, but there is no such thing yet.
The clarifications sometimes are about change that will come in a future
commit, sorry for that. (But the order of commits on this branch is
broken anyway…)
At this moment it no actual providers are present, but the parsing of
ospffile is the bigger part of providing topologies.
Maybe this file is not the good place for that code.
This is a trivial intro message, just to make sure docs can be written
and built.
May serve as a reference commit on how to add new pages to
documentation.
