Hi Ned,

Thank you for answering my e-mail.

I wrote:
> > To be more precise. I have node morphs which are connected through edge
> > morphs. I click on the node and want to duplicate it without its edges.
> > This seems to work, i.e. I get another node without any connectors. But
> > this gets slower and slower fast.

You answered: 
> Try using the context menu copy operations instead of the halo handle.
I looked but I am not sure which operation you mean. copy &
print.../copy to paste buffer? I tried that but the copy operation takes
a long time as well.

(By the way, I when right clicking I get a somewhat different menu
compared to the red halo menu. Is that intentional? Is it a Connectors
feature? I don't get a menu when I right click on a normal rectangle
morph.)

> What is happening is that the veryDeepCopy is copying the edges (and the nodes 
> they attach to...), and hence potentially a big chunk (or all) of the whole 
> graph. I think when I re-factored the packages I lost a couple of copy 
> methods. I will look for them and try to fix this problem as a short term 
> solution.
I suspected something like that. Thanks for offering a short term fix.
However, it is not that urgent. I was just playing around and trying
things out.

> Short answer: I am in the midst of re-thinking the graph model stuff. I would 
> recommend that you postpone using it for a bit, as I will probably rip it out 
> soon and replace it with something quite different.
Ah, good to know.

> A longer answer (and one that might bear some reflection on the list):
> 
> The graph model support that I added is the part of Connectors that I'm least 
> happy with. It turns out that the way I did it (even if copying weren't 
> broken) gets in the way of sharing graph model items between graphs, and also 
> imposes a particular set of decisions as to hierarchical graph structuring 
> and policy.
This sounds interesting. What do you mean exactly with (by?)
hierarchical graph structuring? Being able to collapse a subgraph to a
node in one diagram?

> In particular, there is the problem of allowing a particular domain model 
> object to have different connectivity in different contexts. And there is 
> also the distinction between a Morph and its domain model: original Morphic 
> thought would have them be the same thing in many cases, but a lot of the 
> time you want to look at Morphs as views (hence my separation of graph model 
> items from Morphs).
This tendency of blurring the model-view separation is one of the most
bothering things in Morphic. :/ I think I understand the reasoning
behind it, though. But that's a different topic. :)

> However, this means that things work differently in Worlds with and without 
> graph contexts; in the ones *with* graph contexts, there is a separate 
> structure that represents the "real" graph. Unless this (possibly invisible) 
> structure is maintained in a way that coincides with the user's needs, it 
> will get in the way. An example of this is my desire to have a generic graph 
> iterator morph for Etoys. I'd like such a thing to work in a world where the 
> entire graph model is implicit in the morphs themselves (i.e. what you see is 
> all you get). But I'd also like to be able to use EToys as an extension 
> language for certain kinds of operations on Connectors drawings that have a 
> deeper model.
Generic graph iterator morph sounds interesting. What would you want to
use it for for example?

> I am in the middle of reading Giorgio Busatto's 2002 PhD thesis paper, 
> entitled "An Abstract Model of Hierarchical Graphs and Hierarchical Graph 
> Transformation" (http://theoretica.informatik.uni-oldenburg.de/~giorgio/papers/thesis.ps.gz , 
> 672Kb ).
>
> It is quite interesting and probably should be required reading for anyone 
> interested in hierarchical graphs of any kind. It is also quite readable for 
> someone like me who doesn't have a math or computer science degree (though 
> some familiarity with the concepts and notation of set theory is helpful), 
> and appears to be obviously useful, neither of which I can say about all the 
> graph theory papers that I've read.
Thanks for the reference. I downloaded it and want to read it if time
permits.

> He argues (convincingly, I think) that because one might want to do a number 
> of graph transformations and/or apply various policies to how hierarchical 
> graphs are constructed, it is a bad idea to make excessively clever graph 
> elements (nodes and edges). In fact, his model views the connection 
> relationship between graph elements as an attribute of the graph itself, 
> going so far as to move the knowledge of connectivity from the edges 
> themselves into the graphs (more specifically, into the graph skeleton and 
> its packages).
This sounds almost like an interesting argument against
object-orientation. I must misunderstand what you mean and should
definitely read the paper. ;-)

...snip...

> Among the things that need to be made possible to make this end-user friendly 
> are:
These are interesting but very difficult problems. I won't pretend I
have good ideas about that. Nevertheless some thoughts:

> - specify graph types and policy without having to be a programmer
A graph type could be a subset of available node and edge types. A graph
drawing PasteUpMorph could have a toolbar attached which only contains
the allowed graph elements.

> - create graphical shapes representing specific graph elements (that is, how 
> best to present a focused view of the available graph elements for assocation 
> with the current package)
Isn't it possible right now to use any morph as a graph node?

> - use pluggable transformers and iterators to define operations and policy
I don't understand.

> - see the distinction between the view(s) of the graph and the internal model 
> of the graph (that is, how to make the distinction between (say) deleting the 
> last view of an edge and deleting the edge itself).
This reminds me of UML modeling tools. There you normally have a browser
with a hierarchical list on the left side, which contains the whole
model. You can then create diagrams, where you drag in nodes from the
browser. In the diagram you can select nodes and use a menu operation to
include connected nodes as well. If you delete a node from a diagram you
always delete from the view, if you delete in the browser you delete
from the model. This works because the underlying idea is that you have
no graphical representation of the graph model. 

> I'm interested in ideas for how this could be made useful and powerful from a 
> programmer as well as an end-user point of view.
I'd probably look into existing drawing and CAD programs for
inspiration, e.g. Visio.

This reminds me of one of my favorite applications ever: IntelliDraw.
Can anyone remember it? It was basically a constraint engine based
drawing program. They had some great user interfaces for specifying the
constraints. It was sold from Autodesk to Adobe and was disontinued. I
had hoped they would put at least some of the features into Illustrator
but so far they did not. Maybe the constraints approach is too difficult
to sell to typical graphic designers.

Man, to have that functionality in Squeak would be really, really great!
And that might be a real killer application as well. Especially with a
general enough constraint enging, that can also be used for non
graphical things. However, I feel not competent enough to create a fast
enough constraint engine without a major learning and implementation
effort. And I have already too many projects at once anyway. :(

Bernhard