Ben

Just to be clear - our bounds are not just rectangles. If you have investigated our advance grids system, you'll see that bounds are the limits of an object with respect to the axes of the current grid. We only present a rectangle for ease of common transformations. You'll notice that can become a parallelogram when transformed or selecting an object with shear. Snapping during translation always conforms to the current grid axes, and not the visible selection box. As far as your WYSIWYG issues go - I think I'm loosing your actual point in the avalanche of too many words. How about some concise and short examples of what you mean? I also don't understand your objection to being able to see the immediate effect of tools. This to me is far better than outlined changes with delayed real updates. Too much visual clutter beyond what is needed is often a fine balancing act. It also depends heavily on what discipline you are in when using the tools. For technical drawing, lots of information might be useful. For free illustration, not so much. Believe it or not, some of us on the development team here also have some qualifications and experience, and from a wide range of disciplines. I think cumulatively it will be running well into centuries. Opinions on usability are affected by user experience and knowledge. We have to make our tools to accommodate all levels of expertise - not just those who consider themselves elite in the field. Our choices aren't driven by coding considerations first - but limitations of interface and hardware are always going to have to be a consideration. I'm also afraid that after explaining everything, that silver bullet real world example of what you are asking for is the only thing that is going to motivate us to put work into this. I think I've shown that there is only one specific use case that we are not covering, but I am not convinced of the weight of need for this use case without real evidence. You claimed it is "critical", so you must require it frequently enough that a real example should be easy enough to find?? Beyond this, all the very verbose philosophising is really leading nowhere. This applies to all requests - give an actual example with use case, and we can make some sense of it. And keep it concise - all the excessive noise, personal claims and soap-boxing in these threads is distracting from any relevant point that might be hidden in there.

I don't think using guides achieves anything different to cloning an object and deleting the original. If anything the clone-delete method is potentially faster than using guides. Like I say - defining special behaviour for guides is not going to happen - it would require too much tool development for no real gain.

How exactly do you associate guides with an object? And if the guides are part of the object, don't they still move with the object anyway (as it is being moved, I mean). So what are you snapping to - the original position of the guide again, before you started moving it? Sounds like the same issue to me, just being made more complicated. No - not sure this is a solution. And if it still only addresses this one very specific use case, it is not a justification for adding a whole lot of complicated functionality.

I will just describe a counter use case to what you are requesting - that I know is common. I have a document with a layout of fairly regular objects. I want to correct minor errors in the positioning of a couple of objects that are almost in line with the rest. I rely on bounding box snapping for this. I move an object to allow snapping to pull it into perfect alignment (this might be while also Shift constraining to one axis of movement). If snapping also took into account the original position - I'd end up fighting between snapping to that position and the position I actually want. I'd then have to look carefully at the snapping overlays to ensure that the position is snapping to my intended target and not the original position. This operation then becomes more difficult due to having a rogue snapping target - in fact the very position I am trying to correct away from.

This isn't a question of WYSIWYG tooling. This is primarily the question of predictable behaviour with clear visual cues. Snapping to invisible objects is a nightmare - they can easily interfere with expected behaviour. That is why I say snapping to the original position of an object without a clear visual cue is not good. This also has nothing to do with technological considerations - you are off the mark there. It is 100% down to the reason I give above. I'm also going to argue against your "50% faster operations". What you mean is a 50% faster operation for the one use case you describe - which is actually not a very common operation for most people (given that we haven't had many calls for this behaviour in the 5 years since release,). Beyond constraining a translation to the original position of an object (which can already be achieved by holding Shift) the operation you require is to be able to snap to some demarkation of the object's original position that cannot be determined through constrained motion. Specifically, the main operation is snapping to the centre or opposite edge of the original position of an object while also not making a duplicate (else the original object is still available for snapping). These are the only target positions you'd be able to achieve with bounding box snapping. This is actually a very specific use case when considered against the existing functionality available, and I'd argue (while you say it will be useful to you) whether it justifies compromising the 999 other use cases that people more regularly have? Specifically, your use case (as far as I can ascertain) is the need to snap to the bounds of an object's original position while having no other objects present providing the same alignment, and that cannot be made through just constrained translation. I understand the mechanics of what you are asking for, but can you please elaborate on a real world example for this use case. I mean - where you would use it many times, in order to justify not using the clone-delete method described by others.

One of my pet hates is things snapping to invisible stuff - snapping can produce complex enough interactions with stuff that is visible. So, if snapping to the original position of an object is required, some form of ghost/outline would also be required. You need the visual cues to make sense of what is happening. As I said before, for the most part alignment to the original position is equally achievable by Shift constraining. The positioning will still be the same as if applying bounds snapping to the original position, and so additions to snapping achieves nothing new. The only thing we lack there is alignment to the centre and the edge of the object in the direction of translation. The one area I can see that we don't currently cover is snapping to geometry/nodes of the original positions of an object. This can't be achieved anyway with the Move tool - snapping of curve nodes can only be done in the Node, Pen and Point Transform tools. These tools are busy enough, so adding ghost positions is going to need some considerable thought.

I've thought about vanishing perspective tools - and as @JET_Affinity says, they will have to be completely separate to our standard grids and planes system. From a 2D construction point of view, there is a lot more can be easily determined or inferred in parallel systems. Converging perspective needs distortion - and to preserve any notion of the plane an object lives in is more involved (or even impossible without over-complicating the tools). I will be working more on snapping, grids and custom guides soon. It may well fall into that work, but I am making no promises.

Thing is - adding "ghost" objects to everything that might snap is not a small task. We're talking about quite a few tools. Also - while it is trivial (ish) for the Move tool since we would only preserve the original bounding box for snapping purposes, it is less trivial for the Node tool, Point Transform tool or others. I'll have a think about it as an option for snapping (since it is only really relevant as an extension for snapping purposes). Not going to say when it might get done though.

or use "+=w/2". Even shorter.

This "issue" has been discussed and explained at some great length in other threads. I'm reluctant to go over well trodden ground, other than to say there are some very fundamental reasons why we chose how the modifiers behave. It is 100% intentional. You can have your opinion on this, but our choice of modifier keys is not going to change. While Apple may have decided that Alt should be used for copy, not many apps use combinations of modifier keys to open up greater functionality in the way we do. The keys are so chosen because they relate to how the core tools (Pen, Node, Move) function, physical key placement and cognitive process. The use of both Cmd and Alt for performing cloning has always been a compromise that has annoyed me - but it was made to placate those who see Apple's choices as immoveable (regardless of any wider implications). Had it been down to us, we would only have offered Cmd for cloning. They may not be what you are used to. That is not justification enough for us to break wider usability.

Only just seen this thread. I have to ask - what does having a ghost of the original object give you that cannot be simply achieved by holding down Shift to constrain the translation? The constraining will be perform along the same vectors through which bounding box snapping would be performed - so there is no need for the original object context. Constraining can be toggled on/off at any time during translation. For scaling purposes, snapping can only give you 1:1 with the original shape. The only extra I can see is snapping to the centre line of the original shape (a 50% scale). This can already be achieved by applying a 50% scale in the transform panel. There is no snapping through rotation, so a ghost achieves nothing there. For all other tools, such as the node tool, snapping to invisible original positions is not so helpful and often provides too much snapping visual overload. Constraining is, again, what provides transformation relative to an original position - it has also been balanced with other methods such as constraining a point along it's original line vector (as opposed to grid axes). As usual - I'd ask for use cases to be presented so that we can assess whether a change is justified. We also don't just implement mechanisms because they existed in 20 year old apps. There's a chance that there is a better way.

Unfortunately, that's not the way we roll....

You can already marquee select nodes from the currently selected object, by starting a drag operation outside of the object. You can also start a lasso selection by holding Alt/Option before you start dragging.

Choosing "Overwrite" won't work on files/directories that have restricted permissions. Windows Defender screws around with file access outside of the regular permissions settings. You can't just force through overwriting the file. The error messages you currently see in Designer and Photo were due to us not having had to deal with the specific errors/failures that Windows Defender creates. Changes have been made that will get release in 1.7.2 or 1.7.3 to manage these other issues.

Not after you've successfully opened the file for writing, then it tells you half way through the first write that actually it's not going to let you use that file after all with a spurious error that looks like your drive has died.