|
|
|
|
visualisation default
|
|
|
|
|
|
|
|
|
|
router 172.23.100.1
|
|
|
|
|
position [0 1300]
|
|
|
|
|
|
|
|
|
|
network [172.23.100.10-2]
|
|
|
|
|
# future syntax idea:
|
|
|
|
|
#label hello
|
|
|
|
|
#polyline [0 0] [2 2] [3 3]
|
|
|
|
|
|
|
|
|
|
router 172.23.100.2
|
|
|
|
|
position [400 1300]
|
|
|
|
|
|
|
|
|
|
router 172.23.100.3
|
|
|
|
|
position [300 1800]
|
|
|
|
|
|
|
|
|
|
router 172.23.100.4
|
|
|
|
|
position [0 1700]
|
|
|
|
|
|
|
|
|
|
router 172.23.100.5
|
|
|
|
|
position [400 1700]
|
|
|
|
|
|
|
|
|
|
router 172.23.100.6
|
|
|
|
|
position [300 1600]
|
|
|
|
|
|
|
|
|
|
router 172.23.100.7
|
|
|
|
|
position [0 2100]
|
|
|
|
|
|
|
|
|
|
router 172.23.100.8
|
|
|
|
|
position [400 2100]
|
|
|
|
|
|
|
|
|
|
router 172.23.100.9
|
|
|
|
|
position [200 2500]
|
|
|
|
|
|
|
|
|
|
router 172.23.100.10
|
|
|
|
|
position [200 900]
|
|
|
|
|
|
|
|
|
|
router 192.168.15.1
|
|
|
|
|
position [200 700]
|
|
|
|
|
stubnet 192.168.101.0/24
|
|
|
|
|
position [400 650]
|
|
|
|
|
stubnet 192.168.201.0/24
|
|
|
|
|
position [400 750]
|
|
|
|
|
|
|
|
|
|
router 192.168.15.7
|
|
|
|
|
position [400 200]
|
|
|
|
|
|
|
|
|
|
stubnet 192.168.15.0/24 metric 10
|
|
|
|
|
router 192.168.15.7
|
|
|
|
|
position [600 300]
|
|
|
|
|
stubnet 192.168.0.0/24 metric 20
|
|
|
|
|
router 192.168.15.7
|
|
|
|
|
position [600 200]
|
|
|
|
|
stubnet 192.168.42.0/24 metric 20
|
|
|
|
|
router 192.168.15.7
|
|
|
|
|
position [600 100]
|
|
|
|
|
external 0.0.0.0/0 metric 50
|
|
|
|
|
router 192.168.15.7
|
|
|
|
|
position [200 0]
|
|
|
|
|
|
|
|
|
|
router 192.168.15.10
|
|
|
|
|
position [0 200]
|
|
|
|
|
|
|
|
|
|
router 192.168.15.11
|
|
|
|
|
position [200 200]
|
|
|
|
|
|
|
|
|
|
network [172.23.100.4-3]
|
|
|
|
|
position [0 1500]
|
|
|
|
|
|
|
|
|
|
network [172.23.100.6-3]
|
|
|
|
|
position [400 1500]
|
|
|
|
|
|
|
|
|
|
network [172.23.100.7-3]
|
|
|
|
|
position [0 1900]
|
|
|
|
|
|
|
|
|
|
network [172.23.100.8-3]
|
|
|
|
|
position [400 1900]
|
|
|
|
|
|
|
|
|
|
network [172.23.100.9-2]
|
|
|
|
|
position [200 2300]
|
|
|
|
|
|
|
|
|
|
network [172.23.100.10-2]
|
|
|
|
|
position [200 1100]
|
|
|
|
|
|
|
|
|
|
network [192.168.15.1-10]
|
|
|
|
|
position [200 800]
|
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
|
|
|
hide
|
|
|
|
|
|
|
|
|
|
network [192.168.15.7-24]
|
|
|
|
|
position [200 500]
|
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
|
|
|
style important
|
|
|
|
|
|
|
|
|
|
edge
|
|
|
|
|
source router ...
|
|
|
|
|
target woo woo'
|
|
|
|
|
style important
|
|
|
|
|
|
|
|
|
|
style default
|
|
|
|
|
inherit builtin
|
|
|
|
|
style important
|
|
|
|
|
inherit default
|
|
|
|
|
pen width 14
|
|
|
|
|
pen color ff0000
|
|
|
|
|
icon router bleh.svg
|
|
|
|
|
icon
|
|
|
|
|
|