[Gammaray-interest] Object connectivity: some updates

[Christian Gagneraud]

Hi there,

I have implemented a simple table model on the probe side, and on the
guy side a simple table view with line filter and graphviz layout
selection.
I had to disconnect the VTK viewer, but i'll definitely fix that.
Some screenshot are available at [1], introspecting QtCreator, without
doing anything with it.

The results are encouraging, they somehow resemble the VTK view, but
IMHO with a neater 2 D view (I still think that the 3D view has it's
own strength).

On these images, the connection list is on the left, on the right is
the QG view, upper part is layout selection with very-very basic
tunning, and most importantly, at the bottoms are the metrics:
1. Graph:
 clusters are threads, nodes are objects, and edges are connection b/w
two distinct objects (I filtered out same-object connections for
technical reasons)
2. Perf (single threaded)
  - free, allocate and create a new graph
  - layout the graph
  - clean and render into the QG scene.
3. QG scene:
  - size in inches assuming 72DPI and zoom factor = 1.0 (!?!, thx to graphviz)
  - number of QG items.

First image is the "cluster" layout (aka "osage", can you spot the gui
thread? :))
Second is "radial" (aka "twopi"), with tiny rank separation
Third is radial again, same picture but with bigger rank separation,
interesting parameter...
Forth is "Force (large)", aka. "sfdp", very slow...
Fifth is radial again, but with only 70 objects and 130 connections
Last is "Circular" (aka "circo") with "few" node/edges.

Some layouts simply cannot cope with the number of unfiltered
node/edge: "hierarchical" (aka "dot"), "Energy" (aka "neato"), ... But
once the graph get small they are usable.

The most important missing feature is proper, "clever" and convenient
filtering. The graph needs to be light, the information/noise ratio
needs to minimised.
IMHO, what is being done with the event monitor is a better way to go.
Based on this and on how VTK graph input work, i'm thinking of
changing my model approach.
Following the way VTK handle various properties on graph/node/edges,
i'm thinking of having separate models for each king of "feature"
(cluster/thread, object/node, connection/edges).
Eg, filter the thread list per name, class name, same with object
list. Connections/edges filtering could simply be by type (direct,
queue) but why not signal/slot name as well. And all of them should be
filterable by "id" (that the user got from other tools).
As well, i think that isolated connected components that do not cross
threads should be removed.
Similar to the event monitor, there should be a record filter, and a
display filter.

Still lot of work...

Chris

[1] Screenshots
https://ibb.co/85LVsTK
https://ibb.co/0hRjn2Z
https://ibb.co/fHYRQs1
https://ibb.co/qFxR4DH
https://ibb.co/6XbsSt7
https://ibb.co/dK2psz1