Shift Key constraining movement

Another nice feature of earlier Pans was how in graphics mode, holding down the Shift Key while moving objects constrained the motion to either dead vertical or horizontal. Would this be possible to add?

It does do that. However, you have to press the Shift key after you start dragging the objects. If you hold the Shift key before you click, it toggles the selection. This is standard behavior for modern Mac graphics apps.

I have never encountered that new behaviour. I don’t know what Apple’s own graphic apps do (if there are any) because I haven’t used any, and it’s a while since I used any Adobe products because their current licensing system has priced them way out of my league. But Affinity Designer and Photo still work the way I would expect and hope: shift-clicking an object toggles the selection, but shift-drag (i.e. moving the pointer in between mouse-button down and up) constrains movement of an already-selected object from the start of the drag. Otherwise there would be no point. Merely touching an object can move it in any axis; that’s why I hold shift down first if I need to make sure it only moves in one.

As you say, holding shift before clicking on a selected Panorama object deselects it, even if the click is actually part of a drag action rather than a single click. The workaround for this is to hold shift before dragging an unselected object, because it will then be dragged in the one axis and be marked as selected at the end of the drag. To drag multiple objects with constraint, select all of them except the one under the mouse pointer. That’s somewhat counterintuitive but at least it works.

Not new behavior, it has worked that worked that way since the earliest beta releases.

That’s not the problem you think it is. Start by clicking and dragging, as you say, the object(s) may drag in any direction. But as soon as you press the Shift key, it will hop into alignment with it’s original location. So if you are dragging horizontally, it will keep the original vertical position of the object(s), when dragging vertically, it will keep the original horizontal position.

I thought you were suggesting new to Apple, not new to Panorama. If the former, I haven’t yet come across any others that work this way.

Good point, I hadn’t noticed that. Although once or twice when I tried that it made the wrong decision about which axis I wanted to constrain to — presumably because in the initial movement before pressing shift I had drifted a few pixels in one axis before settling down to moving largely in the other.

For me, holding shift before starting a drag is deeply ingrained behaviour going back 34 years and applies across all the design and typesetting programs that I use. So the ‘Panorama false start’ — 1. start to shift-drag an object; 2. drat! that has deselected it; 3. successfully shift-drag the now-unselected object — is always going to win, I fear.

That’s not how it works. The initial movement doesn’t matter, you can change the direction at any time by dragging the mouse far enough in the actual direction you want to go. If the mouse has moved farther horizontally, the object will move horizontally. If it has moved farther vertically, the object will move vertically. The object will hop to the vertical or horizontal axis depending on the mouse position, but will always remain on an axis.

I just tried this in Keynote, it works exactly the same way, including the selection behavior. I think that is the model I used in deciding how this should work, but it was over a decade ago, so I’m not 100% sure. But I’ve been using Keynote for a long time, and I think it represents Apple’s thinking on this.

Works perfectly.