Ned,

If the "systemWindowEmbedOK" preference is set to false, dropping of 
windows is different from the dropping of naked morphs, and that's 
the distinction you're seeing here.

When "systemWindowEmbedOK" is false, dropping a system window is 
*never* interpreted as an attempt to deposit the window *into* 
another object.  Thus, the logic of seeing whether the putative 
container *would accept* the drop is never triggered.  In this 
regime, all windows belong directly to the World, and all window 
drops are always allowed and always result in returning ownership of 
the window from the Hand to the World, and what's underneath the 
cursor upon drop doesn't come into it.

If, on the other hand, you set "systemWindowEmbedOK" to be true, it 
makes a System Window willing to get dropped into any container that 
it gets released over and that would have it.  So now, if you drop it 
over something that rejects attempted drops, the logic to reject the 
drop kicks in.

This is all a bit *arcane*, but I would argue that there is a 
reasonable consistency to it.  In a windowing-on-the-desktop system 
(systemWindowEmbedOK = false,) it does not make sense to reject any 
window drop, because all window releases drop to the desktop.  In a 
windows-are-just-like-other-morphs system, it makes sense to accept 
or reject window drops just like you accept or reject drops of any 
other morphs.

This is all a bit *nasty*, I agree, but we have certain expectations 
about "window" dNd that are different from our other dNd 
expectations, and it is those windowing expectations that are 
serviced when you have that systemWindowEmbedOK preference set to 
false.

In practice, I think most uses of morphic are either 
more-or-less-purely window-based, or more-or-less-purely naked-morph 
based, so the dissonance where the two metaphors clash is 
comparatively infrequent.

There, I've now said roughly the same thing enough different ways 
that I've *almost* convinced myself that this is reasonable!

  -- Scott

PS:  To state it yet *another* way: the same "inconsistency" can be 
seen in the Mac Finder (for example,) for the same reasons:

If you release a *document icon* over a write-protected folder, the 
drop is interpreted as an attempt to place the document into the 
folder, and since that attempt is not allowed here, the drop is 
actively rejected.

If you release an open *window* over a write-protected folder, the 
drop is interpreted as a window positioning that has no implications 
for filing, and hence there is no rejection.


At 10:02 AM -0700 10/24/01, Ned Konz wrote:
>Right now, there are two different kinds of behavior in the Objects tool when
>you release an object over the Objects tool itself (like if you just click a
>thumbnail):
>
>* SystemWindow derivatives (like everything in the Tools category) stay where
>you dropped them, on top of the Objects tool.
>
>* Other Morphs slide back to the Objects tool and disappear.
>
>It looks like rejectDroppedMorph: isn't being called for the SystemWindows,
>but I haven't really looked into this.
>
>Is this inconsistent behavior desired?
>
>--
>Ned Konz