On Monday 16 August 2004 12:25 am, Bernhard Pieber 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.

Try using the context menu copy operations instead of the halo handle.

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.

But read on.

> I tried to put the morph to the Connectors tab instead of using
> Duplicate. However, dragging it in and dragging it out takes roughly the
> same amount of time.

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.

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.

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).

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.

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.

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).

I think this view would work better in the general case, as it avoids having a 
dual structure that must be maintained separately in the case of the 
Connectors themselves.

Changes to the connectivity of a Connector are the user's assertions and 
desires about changes to the visible part of the graph itself. However, the 
morphs in the current world or other container may themselves only be a 
reflection of part of a larger graph.

By making the graph package (Busatto's term for a particular subset of the 
nodes and edges of the entire graph, itself part of the "hierarchy graph") 
separate and responsible for reflection on connectivity, a number of the 
problems are eliminated.

So questions about connectivity are always delegated to a graph package (what 
I called a "graph context"). This lets us have the same graph element (nodes 
or edges) shared, with some elements visible in some contexts and not others. 

Among the things that need to be made possible to make this end-user friendly 
are:

- specify graph types and policy without having to be a programmer
- 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)
- use pluggable transformers and iterators to define operations and policy
- 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).

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.

Thanks,
-- 
Ned Konz
http://bike-nomad.com/squeak/