Hi Mike,

> So, to clarify. (in theory), the object and cursor would stay in the intended
> view (by which the mouse key was held down) and the viewport would pan
> in that relative direction - instead of crossing over into the next view and
> jumping the object somewhere else.

Yes, but that "jumping" part can be a useful feature that would then be eliminated with the method that you're describing here.

Currently if you want to grab say this back rectangle here and drag it upwards in elevation, you can grab the rectangle in the Top view here:



Then all in one motion without letting up the mouse you can move into the Front view and be adjusting it in elevation here:



That can be a convenient way to adjust elevation - if things worked the way you are describing this kind of multi-viewport dragging would not be possible anymore.


> well, I don't know, is bouncing around with the same object from one view
> to another a common workflow practice? :-/

Basically the split view exists in order to do things generally similar to this like selecting things in the top view and then making adjustments in a different view for elevation.

There is similar functionality in drawing as well - when you draw a curve or a polyline for example you can switch to a different view and place a couple of points in elevation so that you can more easily get a full 3D shape all in one go rather than the drawing being 100% locked to only the first viewport that you clicked the first point in.

It also seems like it would be kind of weird if object dragging was restricted to only be locked to the first view you clicked in but other commands like transforms (move/copy/array/etc) or drawing commands behaved differently and did not lock things or auto pan in the same way.

- Michael