> 
> Hmm. A quick dork reveals that I don't know much about bookmorphs, being
> unable to drag a window into one :) or even resize it.
> 

Hmm, I seem to be a broken record.  Well, I haven't posted this in a
while, so here goes.


In short, there's a preference for this -- systemWindowEmbedOK.  So you
can turn that on and then embed windows all you like.  However, I agree
that windows should be regular morphs, too, and thus that this
preference looks a little funny.  This preference is there for good
reason, though, which you'll probably discover if you turn it on!

The awkwardness I'm hinting at is *accidentally* dropping windows into
holders.  This gets annoying in a hurry!  However, drawing the line at
system windows doesn't seem quite right.  First, this is annoying with
*all* largish morphs, not just with windows -- I've frequently seen
people shift a background image an inch to the side, only to have it
"disappear" into a holder.  Second, people seem to take qutie a while to
catch on to the precise rule that is being used, which can be painful to
watch.  The rule is that the mouse's position determines whether a drop
will happen, and it actually has nothing to do with the position of the
dragged morph.

Here's an alternative, that solves both problems: use the usual rules
for pegs and holes from the physical universe.  That is, if a peg is
smaller than a hole, and the peg is directly over a hole, then it can be
dropped into the hole.  Otherwise, it will just sit on top of the hole. 
This avoids accidents, and has very intuitive rules for humans.

When I suggest this, some people expect that would just trade one
annoyance for a new one: what happens when you *do* want to drop a big
morph into a small holder?  This case is actually easily and quickly
solvable in three ways, however.  Any 3 year old would come up with
three good options:

	1. Squeeze the morph smaller.
	2. Stretch the holder bigger.
	3. Force it.  (i.e., use the "embed" menu)


I played with a system like this for a while, and it seemed fine.  The
code was very simple, too -- there's already a method in PasteUpMorph
that decides whether a morph may be dropped; that method can check
whether the bounds fit or not.


-Lex

PS -- the next layer of windows-as-morphs fun begins when you try to
make things like "activate" work when there are windows at different
levels of embedding.  One tough case is a window embedded in another
window -- the current logic doesn't let them both be active, and thus
it's hard to type into the inner window!