[kepler-dev] Hiding port names

[Tobin Fricke]

On Sun, 25 Jul 2004, Bertram Ludaescher wrote:

> Another nice feature would be a possible color-coding and annotation
> of the arcs (links) between actors. For example, Tobin recently used a
> 30-way (or so) "bus" between two actors. That's an interesting

Ah, right.  I know that these issues are well known, but just for the
purpose of writing them down, here are three issues I've encountered with
the Vergil GUI:

1. Relation 'widths' are not visible from the GUI.

One experiment to try might be to have the line width of the relation as
drawn in the GUI be tied to its width in number of channels.  Or perhaps
there could just be a distinction between width=1 and width>1.

It was non-obvious that I had to do anything to get a multi-relation.
Initially I assumed that I could output to whatever channel numbers I
wanted and they'd get delivered to anybody listening to those channel
numbers.  Actually, you have to set a 'width' parameter on the relation to
set the number of channels it will carry.  I found this by guessing.

2. Connection ordering is not indicated in the GUI.

If you connect up multiple relations to a multiport, then the first one
gets channels [0,X], the next one gets [X+1, X+1+Y], etc.  So the "order
of connection" is important, but it's completely invisible once you've
assembled a model.

I was thinking that maybe some subtle color-coding could be used to
indicate connection ordering, like 0th=black, 1st=blue, 2nd=green, etc.
But this unworkable because relations each have two endpoints, and you
have the same issue on each endpoint.

3. Channel splitting is sort of counterintuitive.

If I connect two relations to a multiport, then some of the channels go to
one relation, and others go to the second relation.

If I use one of the little black diamond "relation" widgets, and connect
it's "output" to multiple ports, then all channels go to all connected
ports.

This distinction is a little strange.  I'm not sure what GUI hints would
help.  Reversing the situation might help: By default all channels will go
to all connected relations, and if you really want the channel splitting
that is currently determined by order-of-connection, then you could use
some channel-splitting widget.

> property of the arc for display. Similary, the arc color might
> indicate some sort of "liveness", or the type of data flowing (or that
> may be an arc label) etc.

In the SDF domain, there's the 'animate' function that shows you the
firing activity of the actors.  I think a useful 'graphical hint of
activity' in the PN domain would be to show the current occupied buffer
size of relations between actors, since in the PN domain relations become
FIFOs.  You're right that throughput is another possibility.  Maybe there
could be a 'relation inspection tool' ("listen to" for relations?) to get
these various parameters.  On the other hand, I haven't felt a strong need
for these things.

> Yet another feature, esp. for long running workflows, is the good old
> "traffic light idea": e.g., in PN, depending on when the process has
> last been known to be "alive", an "LED" of the actor would indicate
> how alive the actor is.

Right, you could have a colored border to the actor (like SDF's 'animate'
hilight) that maps the CPU utilization of that actor's thread to a color.

> the degree of liveness, throughput or something of the sort (currently
> red means active, maybe in this traffic-light setting green would be
> active, yellow would be "congested", and red would be (possibly) dead

Yeah, you could have a whole spectrum a la matlab's 'colormap'.

Tobin