Brad Chapman wrote: > > Whenever a new node is added inside of a Composite Locus (or Network, > for Overflow) all of the unconnected inputs and outputs are > "inherited" by the parent Composite Locus, so that they can > potentially be connected with other loci in the same level as the > parent Composite Locus. This is the situation of things right now if > you grab the latest Piper from CVS. The idea that I had was that the I/O's (links) you DIDN'T want mapped to the parent could be explicitly HIDDEN. This is the opposite of what you propose below (where you bring up some good points), because everything gets mapped by default. I just wanted to mention this, because it is not as though the user could not (when implemented) "unmap" a link. > 1. The composite loci end up with a ton of NetInputs and NetOutputs > (to use Overflow terminology), and I think this will make it really > tough to see what NetInputs and NetOutputs go with which internal > Loci, even when viewing the names of inputs and outputs is implimented. When building a large subnet, I can see how you might end up with dozens of links mapped to the parent, and that could get ugly. > 2. Having been thinking more about it, it seems like this behavior > isn't really what I would want as a default. It seems like that 90% of > the time when I add a new locus I'm planning on connecting it to other > loci in the same network. So, based on this we are doing a lot of > extra work with adding and removing inputs for maybe 10% of the cases > when an input or output will feed to the outside of a network. In > addition, this behavior may be confusing to a user, who wouldn't > expect to see inputs appearing and dissappearing randomly. Good point. > 3. The situation gets messed up when you have a composite inside of > another composite. Then if you add a new locus to the inner composite, > the new inputs are inherited into that composite, and then since they > aren't connected there, are then inherited again into the outer > composite. That's an excellent point and something I didn't consider. > 4. All of the above stuff makes this kind of a pain to maintain, and > also slows things down quite a bit. I can see how slow it is. And we do want to keep communication to a minimum when working through an object broker can make things this slow. > What I'd like to propose is that we change this behavior to be similar > to that used in Overflow. A user would have to click on an input or > output and then specifically request that it be inherited to the > parent locus. Great. I say we go ahead and do that, and we can nix the option to hide a link (explicitly unmapping a link). I think what we can do is place a "P" in the dot, indicating that communication is from/to Parent. In addition, the dot can turn green when its mapped counterpart on the parent is also green. Can the DL send that information (whether the link on the parent is connected or not) to all the child nodes? > The user would then also supply a name for it (like in > Overflow) and then this name would help associate the NetInput with > the internal locus connector to which it is associated. Shouldn't links have names by default? And then the user can change it if they want. BTW, I'm impressed with how far you've gone toward adding Overflow features to Pied. You guys have to check this out! I will be taking the job of developing Pied over from Brad now, which will give him more time for other things. Cheers. Jeff -- J.W. Bizzaro jeff at bioinformatics.org Director, Bioinformatics.org: The Open Lab http://bioinformatics.org/~jeff "Let the machine do the dirty work." -- Kernighan and Ritchie --