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@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