Ben

....just like that. You didn't really read through my lengthy explanation properly then.

So, then we have a different convention for modifier behaviour when dragging an object compared to all our other tools...? And that's logical? Is it not better to have one convention within the realm of a single application.

When you say that, what you mean is that Option affects when dragging an object between UI components. But that convention is a single interaction - it is meaningless for the majority of tool interactions we have. If I drag a handle on a curve - and press Option - what happens? If I drag a control node on a shape and press Option - what happens? Duplication is not a possibility, but momentarily cancelling a snap is. So - for the sake of one type of interaction - moving an object - we have to compromise all other potential tools interactions?? Like I say - there is a much bigger picture that warrants not conforming to a standard that has been defined elsewhere without respect to more complicated tools.

Ok - like I said - you don't agree with it. To say something is illogical implies that we didn't apply logic - when logic is exactly what we applied. The logic we applied extended way beyond the very prescriptive and limiting standard that you are claiming is infallible.

...and as I explained, there is a bigger picture that we thought through at some length. I think I've explained it enough now.

Then I'm not sure how I can explain it to you.... I tried. How about you just accept that we did this all for a reason, in view of how all our tools work, and that it wasn't an accident. Whether you agree with it or not is another matter.

Ok - I'll rephrase - Shift always affects Constraining - either enabling or cancelling. Incidentally, that behaviour has an option in our preferences - you can opt to have object preferred constraining or always on or off.

....and Shift has always been for constraining in any creative app I've used that applies such conventions. I think it's definitely an Adobe standard.

Didn't I just give you a VERY long explanation of how we chose the keys????? 7 posts back.

You can't change the states of the tab or return during a mouse drag process, while also in combination with other keys, such as Cmd. Cmd plus tab or return generate internal command messages. The modifier keys are the only ones that work independently, and can be toggled during a mouse drag operation. Also, if you can circumvent the internal command generation - the key positions are not good if you want to be able to toggle behaviour during your mouse drag. I can't reach the return key unless I abandon any other modifier keys. Having those four keys in close proximity opens up a lot of potential. It's actually one of the limitations in Windows that we only have three keys - we've had to balance what feature we offer across both platforms such that the fourth modifier key is only used for the least common functions in tools.

No - we developed on Mac first.

We started with our fundamental tools in Designer - the Pen and Node tools. We chose keys on how easy they are to use in combination. The Cmd key rests under the thumb so is easier to use in isolation - we chose that to temporarily switch to Node tool while in Pen tool. That opens up a lot of control in Pen tool without having to switch tools. The other three key then sit under your other fingers, which cognitively work independently of your thumb. Shift is always used for constraining - aspect ratio or direction. So that is a fixed convention for us. That leaves the other two keys. We looked into snapping in general, and decided that a way of temporarily cancelling snapping was very useful (note that snapping is not just alignment snapping, but anywhere that a tool snaps to some position). We chose Option/Alt because it worked better with other key combinations while using the Pen/Node tool. Your index finger is easier to operate independently while other fingers are in a static position - so fast toggling of a key under the index finger is easiest. That's a product of musculature and cognitive process. Put all four fingers down flat, and try raise each in turn - you'll see they get progressively harder from index to little finger. Following these conventions we've provided a lot of additional functionality in the Pen and Node tools. The balancing of the use of modifier keys gives capabilities that other vector apps don't offer. We'd also rather follow a single convention across all of our tools, rather than use different modifiers in different tools to provide the same control. Of course, the Apple HIG makes no reference at all to any of these considerations... The Cmd or Option to clone during drag issue came about because we started with Cmd to clone, but a small number of users claimed the Apple convention was infallible and that they couldn't cope - so we had to compromise and enable Option to clone (even though many users already expected it to cancel snapping), against all our intentions.

Can someone refer me to the part of the OSX HIG that states that Option/Alt is only to be used for duplication. The only reference I can find relates to drag-drop between standard UI containers (list boxes, and alike). Can't find any statement that Option/Alt should never be used in any other way. The HIG also only covers modifier key combinations in relation to shortcuts and menu items. It does not make restrictive comment about modifiers in the way that we use them, to augment mouse tool interactions. For example, it makes no comment on widely accepted conventions that extend beyond common UI components - such as Shift to constrain aspect ratio. These concepts are specific to certain types of application, but are still commonplace. So, unless someone can refer to the specific comments on this, just waving around the term "Apple's HIG" is a bit pointless. Bear in mind Apple has passed our application submission (many times) with no issues on us abusing or contravening any of their standards - and believe me, they can be quite pedantic.

@robinpSee above Seriously - can we move on from this - the thread is big enough without going totally off topic on a debate about incorrectly perceived gender insensitivities.

Yes - I did know. He's been on the forum for some time now.

@robinp It's not sexism to refer to someone in terms of their actual gender... more polite I would have thought!? I don't think we need a Political Correctness analysis in this thread, and I don't think we need to find discrimination where there is none.

@va2m I don't think you quite understand. Anything that needs to distort an object such that it is scaled non-uniformly (ie, such as perspective) cannot be reversed using an inverse transform that can simply be derived from just inverting the transform components. If you have something that has been squashed towards the infinite vanishing point, it is impossible to restore the size through a simple inverse scaling - since the object can potentially have been distorted to zero size. Without preserving the data prior to the perspective transform it is also not possible to determine the starting geometry. The perspective plane cannot be derived from the geometry alone. That is what I mean when I say you'd have to preserve some 3D type knowledge of the initial object. Affine transforms can be expressed as translation, scale, rotation and shear components. It is easy to determine an inverse transformation of these. If you need to warp the geometry, the inverse is not easily derived unless you have some way of knowing how that geometry was created. Also, to apply a distortion/warp we have to apply it direct in a destructive manner (akin to how Photoshop applies all its transforms). Our parallel axonometric system requires no destructive changes to the base geometry. This is the major difference. Vanishing perspective tools will come eventually, but they will work in an entirely different way to our parallel axonometric tools.

Not necessarily bigger, but just one that makes sense of a need that cannot be achieved any other way. I'm also still not convinced that the clone+delete method isn't good enough in common practice. It only takes a fraction longer, and the extended examples in those videos demonstrate that the result is better achieved with power duplicate anyway - so I still only see people struggling to maintain their choice of workflow against more powerful tools already available in Affinity. The positioning is usually only required for the first couple of instances - power duplicate should take care of the rest. That binary cloning approach is pure madness anyway when it can already be done quicker - even if using some temporary objects to set up the initial offsets. The self-snapping positioning shown in the examples to me seems so specific that the real justification still has not been met to warrant compromising the common use of the tools. Are there any other examples other than this regular pattern stuff???

Interesting. I'll have a think on that one. We now also have an on-spread grid widget that will let you construct a grid manually to conform to other geometry.

Limiting features are justifiable, only as long as they do not hamper the common use cases for a tool. If that rare use case requires yet another feature switch we'll get others critical of "feature overload" or "too many options". As I said before, most people doing layout work would hate having objects snapping to their original positions. There is really no use in it. You are always trying to move an object away from where it was, and align it to something else. To have it fighting against that (pulling back to its original position via snapping) seems unproductive. If I need to keep an object aligned to where it was, I use Shift to constrain the movement. The only use cases I see so far all relate to forming regular patterns of same objects, unless anyone can elaborate any others..?

Exactly - still no need to snap an object to its own original position.

Can anyone else can clarify this - is there really ever a need, in total isolation, to snap an object to itself? Of all the supposed "use cases" in this thread (which I don't need repeating) - how many cannot be achieved with Power Duplicate, or using an appropriate grid for positioning cloned objects? (or a combination of grid + power duplicate). Creating a regular pattern of objects seems to call for a grid approach, to me. Using self-snapping you can only ever create spacing that is the same as the size of the object - a somewhat limiting approach I'd argue. A grid would allow centred positioning of clones - independent of the object size.

Well done, that man - and you did it without telling me about your childhood, pets, holiday, private train of consciousness, or philosophies on the English language and use of modern computing terminology. Kudos also for the reference to the "Homer Simpson car"... spot on, and illustrates the point I've tried to make about us pandering to all unmerited feature requests.

TL;DR Can someone distill the useful points from this thread for me... thanks.

That doesn't surprise me. On Mac all four fingers lie just nicely. It's the reason why we picked Command to drill through to Node tool, because your thumb works separately to the other three modifiers - and the main reason we are being stubborn about Alt being used for cancelling snapping (and not cloning). I also hate trackpads in general. I'd rather be using a mouse.