Also, by holding Control key when doing this, performs a resize of the
morph in place, including SystemWindows.

And once you get used to moving _everything_ this way, including
SystemWindows, you'll never go back to using the title bar for moving
windows.

Together, these gestures reduce time spent moving/resizing windows by
a significant factor.  I've gotten used to it, and it's really
noticeable when I have to operate in a conventional windowing
environment that doesn't support this because it's back to a
fine-motor aim for every move and resize and it feels cumbersome..


On Tue, Apr 3, 2012 at 3:38 AM, Scott Wallace <SqueakList at pacbell.net> wrote:
> On Mar 31, 2012, at 4:58 AM, Stéphane Rollandin wrote:
>
>>> Well, that was the primary _effect_ I want -- not a side-effect.
>>
>> Sorry but that is not acceptable. For fine-tuning of the morph position, the halo must be stable: just grabing the handle should not move the morph.
>
> It bears mentioning that cmd-drag is an exact equivalent to brown-handle-drag (i.e. as you drag, it repositions the object within its container,) but with the advantage that the point of contact for the drag is on the object, not on a halo handle outside the object's bounds.
>
> This allows precise positioning (even at the top of the screen,) with none of the disadvantages that have been mentioned in this thread.
>
> (By cmd-drag I mean use whatever mouse-button and perhaps modifier key gesture you normally use to bring up the halo on a morph, but instead of *cmd-clicking* on the morph, "cmd-drag" it by moving the mouse with that same mouse button down.)
>
> -- Scott