Commit Graph

2 Commits (6b2772d16028b561892b5232c42052600e7d4ef9)

Author SHA1 Message Date
LEdoian 6b2772d160 Extend visualisation.ospf to include styles
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)
1 year ago
LEdoian 7cfa7ea2bf Split visualisation directives to separate file.
This allows us to safely reuse the OspfFileTopologyParser without having
it ignore unknown directives.
1 year ago