On Friday 05 April 2002 07:23 am, danielv at netvision.net.il wrote:
> Ned Konz <ned at bike-nomad.com> (by way of Ned Konz <ned at bike-nomad.com>) 
wrote:
> > On Thursday 04 April 2002 08:23 am, Daniel wrote:
> > > A few question/weird things that happen:
> > > * When I duplicate an arrow (grab by green handle), the grabbed object
> > > appears at a significant offset to the original. This is a bit
> > > annoying. Ah, I just understood, it hands me the first connection
> > > point, so I can start connecting immediately. This is the idea?
> >
> > Yes. You can then drop the first connection point on something.
>
> What bothers me is that AFAICT, the green duplicate handle is pretty
> fixed in meaning "you've just picked up a copy by it's green handle". So
> I very much expect the green-grab not to immediately move the copy...

OK, so I changed it so that it behaves as with other Morphs.

> > Though
> > duplicate on a connected line doesn't let you drag the line (I'm going to
> > fix it so it disconnects the line, I think; what are your feelings on
> > this?)
> >
> > What would you rather have it do?
>
> How about distinguishing between a green handle grab (carry off a
> disconnected clone) and a green handle click (start defining a line,
> source first using crosshairs)?
>
> Is this also usefully applicable to other morphs?

I think this would be somewhat inconsistent. Right now if you click on the 
green handle you get a duplicate in hand. Likewise if you drag the green 
handle. If people are used to clicking to get a copy this could be 
irritating.

> [Request for midarrow constraints]
>
> > You can make a constraint object with an attached shape.
> > Create a new NCConstraintMorph, attach it to where you want it, and say
> > "add arbitrary shape". It will then copy the shape you select and add it
> > to itself.
>
> Hah! I tried that, by creating a bend in one of the arrow, doing show
> handles, thus getting the constraint. Then I created an ellipse (didn't
> know you had those NCEllipses, they're not in any flap - found them
> looking for NCConstraint in new morph menu, which it doesn't show up
> in), and did add arbitrary shape on it. This got me almost what I want -
> the line did connect to the ellipse by the middle.
>
> However, two things -
> * The ellipse was connected to the line, not vice versa - I expect the
> lines to be moved the ellipse, not the other way around... I don't think
> I understand the idea yet.

The ellipse was in effect part of the label you added. So it'll follow the 
line.

> * Like you said, this copies the ellipse. This means I'll never get what
> I really want (and so obviously didn't mention ;-), which is several
> lines passing through the same ellipse. Can you explain why the copy?
> seems if I wanted a copy, I could do it myself before doing a pure
> connect...

The copy is so you can decorate several line ends with the same shape.

Anyway, 

> There are a few concepts that don't quite connect in my head -
> * In morphic, morphs move with the parents. Constraints are also part of
> the submorph heirarchy.

And do, in general, move with their parents (like when you are dragging the 
whole morph about, rather than one of its ends).

However, since the constraints are stepping (most of the time), and are 
re-positioning themselves and the line ends they're responsible for moving 
(their constrained instvars), they quickly correct their positions. This is 
why you can drag on the middle of a Connector and have the ends stay 
anchored.

> * but Constraints move with their inputs?

Yes. Or more accurately, move with the results of their constraint, which is 
usually dependent on their inputs.

> * Constraints affect the morphs in the "constrained" arrays by sending
> them messages. right?

Yes. This is in applyConstraint: .

> Is there a design overview somewhere?

No, but there should be (I'm going to be writing at least one magazine article 
on this as well as a reference guide).

> > If you don't mind coding, the NCConstraintMorph (or
> > OffsetConstriantMorph) could have a subclass that moves line vectors
> > around. (is that what you want?).
>
> didn't understand "move line vectors"..

Sorry, typo. I meant "vertices". Just as NCLineEndConstraintMorph now moves 
line ends, a similar constraint could move in-between vertices.

But the in-between vertices are tricky to hold on to, since they come and go 
as the user edits the line. What would happen, for instance, if the user 
chose "straighten" on a line that was attached in the center to something? 
Would that attachment go away?

I suppose that these constraints could affect the nearest vertex; this would 
allow for new vertices to be inserted on either side.

> > Or maybe I could get the LineEndConstraintMorph to work with other line
> > vertices. I don't know how much work that is.
> >
> > > * A questions that's only somewhat related - I want to store my
> > > diagrams outside the image, maybe in a BSS-like DSS
> > > (DanielsSuperSwiki), probably to be kept internal.
> >
> > Make them separate projects, then just save the projects.
>
> Yup, that's what I've been doing so far...
>
> > > Any better ideas? how do I set up my own SSwiki?
> >
> > I don't know. However, I've had some success using a ComSwiki set up with
> > project pages that make new drawings. One of the reasons I changed from
> > using BlockContexts to MessageSends is so I could get this to work.
> >
> > The nice thing about this is that it allows collaborative work (I don't
> > know what it does about concurrent edits, though).
>
> Sounds great - since I already keep my hyper text notes in a ComSwiki,
> that matches perfectly. So how do you edit a diagram that's in the
> ComSwiki?

Just go to the page, and it's live. You edit the diagram, and hit the "save" 
button. See the ComSwiki "project pages" documentation.

I have a page on my Swiki for trying this; you can try it if you want...
http://nedkonz.dhs.org:8080/Ned/19

> > Thanks for the feedback!
> >
> > BTW, what do you think about Connectors and:
> > * orthogonal lines
>
> So far, I don't need them

good. Perhaps in a future version...

> > * undo
>
> Surprisingly, so far, I haven't needed that either ;-) but this would
> certainly be great as a safety net.

So what should be undoable? Deletions, certainly, but how would undoing a move 
or a connection work (since these things are moving themselves most of the 
time)?

-- 
Ned Konz
currently: Stanwood, WA
email:     ned at bike-nomad.com
homepage:  http://bike-nomad.com