ch3 final?

en/chap03.tex

@@ -289,25 +289,23 @@ they only tag vertices and edges with styling dictionaries. This provides
 something similar to an interface, helping to uncouple the style from the
 specific Annotator that provided the respective data. Each Annotator which
 provides data worth showing has a companion StyleAnnotator to provide the
-respective style.
+respective style. When drawing, we pick one StyleAnnotator and highlight data
+according to it.
 
-The styling dictionaries are then combined in a MegaStyler, another
-StyleAnnotator. The MegaStyler ensures other StyleAnnotators are run and
-combines the styles in order of importance (the bitwise-or operation on
-dictionaries is used, so that the styles for more important StyleAnnotators
-override the previous appearance).
-
-We considered using stylesheets similar to CSS, but we think that
-approach is too heavy-weight. Rather, assigning priorities to the
-StyleAnnotators could allow a more flexible order of applying styles, but at
-this point this also seems like a unnecessary complication of the project.
+The current approach avoids mixing styles from multiple Annotators, which might
+be required for more advanced use in the future. We considered using
+stylesheets similar to CSS, but we think that approach is too heavy-weight.
+Rather, assigning priorities to the StyleAnnotators could allow a flexible
+order of applying styles, but at this point this also seems like a unnecessary
+complication of the project.
 
 We let the user decide, where the vertices should be placed, because they might
 have some idea or understanding of the system that is not present in the
 topology. For this reason, we also ignore classical metrics of graph drawing,
 like the crossing number of the layout. This can be demonstrated on the default
 Gennet topology: while it forms a planar graph, it makes more sense to let the
-edges cross, because the layered structure is more important.
+edges cross as on figure~\ref{fig:gennet}, because the layered structure is
+more important.
 
 To store the placement, we reuse the ospffile format. An example is shown in
 listing~\ref{lst:visufile}. The top-level contains a \verb|visualisation|
@@ -316,7 +314,9 @@ future. Level-2 contains vertex specification in the same format as in dumps
 from BIRD. On level-3 there is a \verb|position| directive with the
 coordinates, but for transit networks, additional details (DR or address) can
 be provided to specify the correct network. Similarly, we allow a \verb|router|
-level-3 directive to be used in the \verb|stubnet| block.
+level-3 directive to be used in the \verb|stubnet| block. This format allows
+using BIRD's output as the basis for the placement file and could be extended
+by other directives if needed in the future.
 
 \begin{lstlisting}[float=h,label=lst:visufile,caption=Vertex placement description]
 visualisation
@@ -327,10 +327,6 @@ visualisation
 		dr 192.0.2.14
 \end{lstlisting}
 
-This format allows using BIRD's output as the basis for the visualisation file
-and could be extended by other directives if needed in the future. The
-visualisation file is loaded by the PlaceVerticesFromFile Annotator.
-
 We try to place vertices without known position in proximity to already placed
 neighbours, so that the user can easily locate them. Since the neighbours can
 also have unknown position, BFS is used: we place the vertices of known
@@ -349,25 +345,7 @@ exploring this idea.
 
 \lstinputlisting[float=h,label=lst:graphviz,caption=Author's home topology]{../img/graphviz-fail/source.dot}
 
-% Imagine the figure here, but LaTeX does not re-order figures.
-
-The display of the topology is then straight-forward. We just take the
-Annotation from MegaStyler and create graphics objects for each vertex and
-edge. The Graphics view framework allows us to set z-values of the sprites,
-which we exploit when highlighting objects -- we create a bigger
-semi-transparent object below the actual one. An example of the graphical representation is on figure~\ref{fig:ui-highlight}
-
-\begin{figure}[b]
-	\centering
-	\X{fig:ui-highlight}
-	\caption{An example of a highlighted vertex and an edge}
-	\label{fig:ui-highlight}
-\end{figure}
-
-The Qt framework has built-in support for dragging items, so our GUI can also
-be used to modify the positions of vertices.
-
-\begin{figure}[t]
+\begin{figure}[h]
 	\centering
 	\begin{subfigure}[b]{0.8\textwidth}
 		\centering
@@ -402,3 +380,31 @@ be used to modify the positions of vertices.
 	\caption{The unpleasant results of Graphviz's layout engines}
 	\label{fig:graphviz}
 \end{figure}
+
+In order to display the topology, we convert it to a simple undirected graph.
+The set of vertices stays the same, the edges are only reduced to a pair of
+VertexID without having any kind of cost associated with it. The only tricky
+part is deciding the style of the new edge when the StyleAnnotator returned
+multiple styles for the unified edge. We decided to pick the style of the
+lightest positive-cost edge, since it is the most relevant in most cases:
+zero-cost edges are almost always network-to-router edges\footnote{We are not
+sure whether other zero-cost edges are permitted.} and heavier edges are not
+used, because it is always cheaper to use the light edge. (We are aware that
+this is not true for asymmetrically configured point-to-point links, but we do
+not think they are commonly deployed.)
+
+Since we will be able to use edges in sets, we need a canonical hashable
+representation. For that, we implement a total ordering on VertexIDs, which
+allows us to use pairs of the VertexIDs in ascending order to reference the
+edge. There are currently no specific requirements for the ordering to satisfy.
+
+The vertices and edges of the simple graph have a one-to-one mapping to the
+actual graphics items shown to the user. The Graphics view framework allows us
+to create nested items, which we use for highlighting: a highlight is just a
+bigger rectangle in a lower layer than the displayed object. Moreover, the
+framework has built-in support for dragging and right-clicking objects, which
+simplifies creating the UI.
+
+Currently, the MainWindow object acts as a coordinator of everything that needs
+to happen, from loading topologies and annotating them to putting them on the
+scene and allowing the user to interact with them.