Named connection points?

[Dan Katz <dpkatz bc gmail com>]

Hi -

I'm doing a bunch of work on yet another Python diagram->code
generator plugin, and several times now I've found myself wishing that
connection points (and handles, to a lesser extent) had names that
were assignable in the Custom Shape Module shape files and accessible
through the Python API.  I actually got so far as beginning to hack
the C code to add this capability when I found that Dia actually used
to have named connection points and that they were removed in 2009
(https://mail.gnome.org/archives/commits-list/2009-August/msg00148.html).
 I guess I have two questions:  could we bring back named connection
points, and if not, then how do people usually deal with the issues
I'm having.

A bit of context:  I'm writing a Python plug-in for Dia which
translates a data-flow diagram to code in a home-grown legacy
job-control language.  The plugin is exposed as an export filter (like
codegen.py and siblings) and follows the usual compiler design of a
front end which parses the diagram into a logical graph structure and
a back end that walks the graph to emit the code.  This parsing job is
quite easy in a Dia diagram, of course, since the structured nature of
the diagrams makes them quite easy to parse based on object type and
since the custom shapes module allows us to define  domain-specialized
shapes with different object types.  For my domain, I've defined a set
of custom objects I've built to represent the various relevant
job-control operations, and since the diagram objects map directly to
the domain semantics the parsing is very clean.  In addition, since
these are custom shapes I have full control of the connection point
set, and I take advantage of that to cut down the number of connection
points in a shape to the minimal semantically meaningful set.  For
instance, I might have a "differencer" which logically takes 2 inputs
and produces the difference on the output.  The custom shape for this
"differencer" would have exactly 3 connection points - perhaps a
triangle shape with 2 connection points on the left for the inputs and
one the right for the output (it'd look sort of like an op-amp symbol
from circuit diagrams).  Limiting the connection point (CP) set in
this way means that I can assign semantics to the connection points
(the top left CP is the minuend, the bottom left CP is the subtrahend,
the far right CP is the difference) and makes it more difficult for
users to draw nonsensical diagrams (i.e. write nonsensical programs).
So far, this is all excellent.

The annoyance comes when I want to differentiate among the connection
points in the back-end pass of the Python code generator.  I'd like to
be able to name the connection points as part of the custom object
definition (e.g. 'minuend', 'subtrahend', 'difference') and then  then
get them by name in the Python API.  In my imagination, the change in
the shape file would look something like this (a small syntactic
extension to what's there today):

   <connection>
       <point x="2" y="3" name="minuend"/>
       <point x="2" y="5" name="subtrahend"/>
       <point x="6" y="4" name="difference"/>
   <connections>

(where the name attribute is optional, of course, defaulting to the
empty string) and would then allow code like

   foo = [c for c in differencer.connections if c.name() == 'minuend']

which is rather cleaner than what I'm doing now which involves things
like getting the list of connections and sorting the connections by
y-coordinate to find the 'top' one and knowing that 'top'='minuend',
or sorting by x-coordinate and knowing that the right-most connection
point is the output.  (In fact, is that sort of logic even reliable in
the face of actions like "Flip horizontal"?  I haven't checked that…)
Today I can get connection points by geometry ("get me the top left
connection point"), but I'd rather get them logically ("get me the
'difference' connection point").  Obviously there are many cases where
this doesn't matter, but to implement semantics for non-commutative
operations (subtraction, division, exponentiation, patch application,
etc.) being able to know which CP is which matters a lot.

> From the code diff in the message I cited above reporting the
elimination of connection point names, it looks like connection points
used to have a pretty clean concept of a name, and also looks like
that concept had not been exposed through the Custom Shape Module (if
that existed back then).  I recognize that this connection point
naming capability is probably pretty useless when using Dia primarily
to draw a picture for human visual consumption, but it seems valuable
in the context of accessing objects through the Python interface and
wanting to assign domain semantics to particular connection points - a
context that the Custom Shape Module and the python extension system
taken together would seem to encourage if the number of
code-generation projects that seem to come up on this list is any
guide.  The check-in comment removing named CPs claimed lack of use in
the core objects and some memory savings as the rationale for deleting
them.  My use case, though, involves custom objects rather than core
objects, and I'm not sure that the memory savings is that big a deal
(although you folks would know better).

So once again my questions are:  Could we bring back connection point
names?  Are there strong technical reasons not to do so?  And what
approaches do people use today to ensure that the semantics they want
to assign to connection points are reliable and cleanly defined?  Is
there a better approach than the geometric sorting that I'm using now?


Thanks.

Dan