JET_Affinity

This is a proposal for an alternative way of interacting with Béziers that is lacking in the consumer vector design program space, though most of these have existed for years or decades with font design tools. I wrote it up to outline some key problems with vector handling in Affinity Designer and suggest a potential solution.

1. Diagnosis: "robust"
Currently Affinity Designer has a flimsiness problem with its current bezier tools. What I mean is that once a change to curvature must be made, it is difficult to make it consistently and parametrically. A "robust" set of tools is one in which the behaviours are consistent, expectable, and where as many transformations as possible can be done incrementally (i.e. without relying on the mouse motion to drag things into place). It should be possible to access basic transformations (translate, scale, rotate, skew) on any parts of the curvature (segments, anchors, BCPs, whole objects) in any combination, independantly of one another, with no unnecessary steps.
We can move anchor points and their BCPs ('handles', Bezier Control Points) with the mouse pointer, and we can snap them, but we can only use the anchors themselves to apply transformations or shift them with arrow keys. We also have no good way of applying transformations to even the anchors themselves if the group we wish to transform belongs to more than 1 vector layer. What this inevitably means is that for relatively simple transformations of curvature, if one does not settle for changing handle positions individually, they are required to set up elaborate grids, relying on the snapping mechanics of anchors and BCPs, which does work to achieve a final goal, but is not good for exploring a range of possibilities. If the same transformation has to be made to another part of the curvature (let alone one at an angle relative to the original), that necessitates extensive re-positioning. There are also many lacking aspects of managing curvature, such as no good ways of adding BCPs to straight line segments, inconsistent results in converting between smooth and sharp anchors, and no way to move an anchor point between its BCPs.

2. Applicability
Though I will propose many features found in e.g. font design software, this is not an attempt to turn Affinity Designer into a makeshift font editor or anything of the like. Since the software is relatively specialised and I imagine not many users of the Affinity suite have experience with it, I am bringing the lack of its features to light because I think anyone who uses Béziers would find them useful in their process, but it is impossible to desire what one doesn't know to exist. More robust Bézier tools touch on every aspect of vector work and make significantly easier the processes of, for example, editing expanded typography, designing ornaments, designing frames, creating precise logos or icons, digitising raster drawings, ensuring consistency in curvature (+ removing 'sharp points'), fine-tuning masks, creating consistent shapes not covered by the shape tools, working on anything technical where things like G-continuity and/or consistency of curvature make a significant impact, or even reliably editing meshes, which at the moment is extremely labourious. Currently Illustrator has the same problem; often editing a mesh for a specific purpose is more trouble than it's worth, given that the end result is not even guaranteed to be good and may need to be adjusted later.

3. Examples of robust vector tools
Most good examples of good vector handling are common within font tools, which is not very suprising given that their premise is precise vector output. For that reason I think Designer could pick up a few things common in font tools. The absence of these features in regular vector design programs could be partly because they create a lot of visual complexity with even a small number of elements. However, as I will propose later down the line, Designer already has a solution to allowing different types of editing and hiding their visual clutter which would make it possible to isolate selected objects and allow editing them comprehensively. Below are some examples of what I outlined before and a brief summary.

In Glyphs, BCPs can be selected independantly from their anchors and are given their own bounding box. They may be nudged by arrows or transformed by scaling or rotating by dragging or with precise parameters. Option-clicking on a straight line segment places both missing BCPs on the line segment. Double-clicking on an anchor point or pressing 'return' with any number of anchors selected turns them from a corner points (blue) to a smooth points (orange) — meaning the BCPs on their sides are always aligned. Being able to toggle between these two options is extremely useful, especially if it is possible to ensure only one BCP realigns (currently affinity designer displays smooth anchors as round but with the same colour which should be editable separately, and when converting from sharp to smooth, both BCPs change position. I think there should be an option to have a more predictable behaviour in that place) Also notice how despite being two separate objects, all the BCPs and anchors can be selected and transformed together.

There was already a post that suggested the option to view curvature combs. I will not reiterate their usefulness, only specify that the option to display them is in my view a useful tool to model Béziers with precision.
On the right of the image is a use case of having clearly defined corner and smooth points in curvature; the BCP on the right of the orange point always aligns with the line that leads into the point, thus moving it around always generates a straight line that curves downwards without performing any additional steps. This is not a call for 'that specific feature.' Rather I am attempting to demonstrate that some simple shifts in how the curves are handled can be very powerful for editing and exploring within the program. I believe many font tools are at the current 'apex' of the power the user has by virtue of nothing other than just their handling of Bézier curves.    

There area also more specific vector tools that make mundane tasks much easier. The I-disconnector, for instance, is similar to the knife tool, except it also allows a specified amount of overlap to be generated. The disconnectors in general are useful for breaking down more complicated shapes with minimal effort. I could understand such things never making their way to the program. I put them into this post only to demonstrate how many core vector features are possible (but largely unexplored) within software like Designer or Ai for simplifying mundane daily tasks that consume a long time when they must be done.
Brief list of integral features for precise editing of vector paths:
Independently selectable anchor points and BCPs (independent of one another and the selected object in the layers window) A convenient way to rotate and scale from an anchor point. The current behaviour of having to manually drag the anchor point from the centre of selection each time is too slow. This feature is good for layers because they remember where their anchor point is, but for more temporary selections another solution should exist. More consistent conversion between smooth and corner anchors and possibility to display the distinction clearer Curvature combs On hold of [whatever key modifier] and arrow keys, the selected BCP moves along side an extension of its original 'line' from its anchor point (this already happens with shift-dragging) and on hold of [the same modifier] the smooth anchor point is moved between its BCPs and the corner point is moved independently of its BCPs, such that in both cases only the anchor is moved and the BCPs stay in place (both with arrows and with mouse dragging). Below are some of the sources of features and potential sources of additional features that would benefit Affinity Designer in my view. The reason I list them is to show the breadth of how much can be done with Bézier curves alone, and why all those features could be placed into a Persona of its own (however radical or far-fetched it may feel). I would however suggest improving the basics of curve handling before an application of any of these is considered. 
Most of the proposed features come directly from Glyphs 3. There is of course much more to Glyphs. I could only wish for its segment component functionality to make its way to Designer's Symbols window.  The disconnectors come from DTL FM2. They are available in DTL LetterModeller. It can be a bit tricky to get into the font editor in LeMo. It has a lot of other really useful features that I didn't mention because I intend this post to primarily propose features that would be 'unlocked' to the user with only a difference in the handling of existing functionality within the software. However one 'separatable' feature I particularly like is the Shift Smooth, which is a way of moving an anchor point and recalculates all 4 BCPs of its adjecent line segments to maintain the smoothness of curvature. The curvature combs I showed come from Yanone's Speedpunk, which is a FOSS extension to RoboFont and Glyphs. Including this feature is part of why I am intent on proposing all these together as one Persona rather than individually — displaying this information in particular can be computationally intense if done by accident in an e.g. illustration process, so I think it should not be possible to accidentally enable it within a process that wouldn't make use of them. A lot of other useful functionality exists in the spaces of plug-ins for RoboFont and Glyphs. 
4. Why the proposal? Is it even suitable?
There are many things that Affinity Designer aims to be, and I know certain features, e.g. auto trace, are very often requested by people who wish to get as far away from Adobe's pricing model as they can. I notice that recently it also aims to be a bit of precision tool, allowing import and editing of CAD files which can also be locked behind an oppressive subscription. I believe that this is a strong point for both, providing features that most people would use and find indispensible after having tried them, and ones that people who need precision would be very happy about. They strenghten the core of what a vector design program is. The people who need precision are not just the few who cannot live without CAD support within Affinity Designer, but also anyone who e.g. designs a precise icon or logo, customises type for a large poster or mural, or just isn't sure where the object they want lies on the scale from squircle to circle to diamond, and doesn't have 4 hours to set up an elaborate grid and move the BCPS one by one, through one iteration by another.
The reason I think Affinity Designer is uniquely suited for these features is because though they make life much easier, they can introduce a lot of visual clutter, which Designer already has a way of dealing with; the Personas. Dedicating one entirely to much stronger vector functionality seems to me like a good place for features that are sorely missing from the entire space, one only this particular program could provide effectively as it stands (which is why I elected to put this proposal here rather than e.g. sending it to Adobe, whatever that could have accomplished.) I am also admittedly a bit sick of creating a new font file whenever I want to edit an SVG with a modicum of speed and accuracy, despite having access to both Designer and Adobe Illustrator.
To end my million-word bézier novella, I want to clarify that it doesn't matter to me how the issues I brought up are addressed if only they are. The methods used by font software are of course tried and working well; everyone I know with experience using font tools tends to edit paths within them, even if that means having to paste them from and back into other software, not to mention reposition them. If nothing changes about Affinity Designer, then that is just what I will keep on doing, but I think it would be neat if this functionality was more accessible. To anyone yet unconvinced, I urge you to download a free trial of FontLab (mac/win) or Glyphs (mac only) and spend a few hours editing paths within them, then see how you feel after returning to Designer. A testimony on the Glyphs website says: "After using Glyphs, the pen tool in Illustrator feels like carving a chicken with a chainsaw." That it does, and I'm afraid Designer currently feels quite the same, but it has the potential to make Illustrator feel like that in comparison.

Like baoyu said, I would certainly expect the new scripting API feature to be major enough to justify the next pay-for major release. I'd be quite willing to pay for upgrading to the new version of all three apps.
Regarding fde101's concerns:
I completely disagree with the assumption that 'casual users' would "write off" the scripting feature, whether they are ready to write scripts themselves or not. Just look at Inkscape's Extensions menu. That effectively is Inkscape's built-in scripting implementation. But it doesn't just empower scripting users. A long list of Extensions are included with the standard download of Inkscape, and any user can pick and choose from hundreds of additional free Extensions that are created by other users. Inkscape would be far less capable to all of its users without its Extensions.
Prior to Adobe's Captive Customers rip-off licensing, I built a considerable number of Illustrator scripts in its Javascript-based scripting environment. But I've only just very recently started dinking around with Inkscape's Python-based extensions. That certainly didn't keep me from having Inkscape on-hand and using its Extensions for many years. Again, Inkscape would be far less capable to all of its users without its Extensions. I would certainly be surprised if the first release of Affinity's scripting didn't come with a broadly-useful set of pre-built ready-to-use scripts that demonstrate its power and potential.
Many users in this forum have pined for Serif to implement support for commercial 'plug-ins'. I consider that approach to adding bespoke features archaic, passe', inflexible, and needlessly costly. Providing a well-done scripting API has far more potential. Scripting users will no doubt be sharing the scripts they create with other users, either for free or for a small price.
Another misconception (I think; corrections welcome) evidenced in this thread is the notion that a program that has a scripting API has to have some kind of explicit built-in 'support for AI' in order to use an AI Chat to help writing scripts for it. I'm  no programmer and don't play one on the internet. But as I understand it, AI Chats fetch from whatever is 'out there' on the subject. While Inkscape 1.4 came out late last year, you can still get help from an AI Chat about writing Extensions for Inkscape, and it can even return fully-functional Extension scripts that work in earlier versions. Sure, new versions of software (for example, FileMaker Pro) are scrambling to add AI-centric access to AI from within the program's standard interface. That doesn't mean I can't use AI Chat to assist in building a complicated relational database structure in an earlier version of FileMaker.
JET

Can't agree any more! We want a layer system that de-couples from the artboard in designer.

You could make Assets for your suits, and just drag them from the Asset Panel onto the page... It's what I do.

I've said this before in other threads, but it is pertinent to this thread, too. so...
Every serious vector-based illustration program should provide for transforming selections disproportionally in any direction needed, not just horizontally and vertically.
So first, it is a very good thing that Affinity bounding boxes 'remember' their contents' rotation. Since Affinity does not provide transform tools, but only provides transform handles on bounding boxes, that is the only way to perform on-page scaling in directions other than vertical and horizontal. Yes, I agree that one should be able to permanently re-set an object's to page-normal when desired, but a rotated bounding box is a very useful thing.
Inkscape, for one example, insists on all bounding boxes always being page-normal. So when you need to scale a rotated  selection in the direction of its rotated orientation, you have to 'un-rotate' it so that the desired direction of scaling is either horizontal or vertical, perform the scaling, and then re-rotate it to its intended orientation. That's needlessly tedious.
But Affinity's treatment is still senselessly limited. Consider an object that is rotated 35 degrees. Its rotated bounding box is 'remembered'. So you can disproportionately scale it in either the 35 degree or 125 degree directions. But by what logic is it assumed that the illustrator does not need to scale the rotated object in some other direction that is pertinent and meaningful to the illustration.
Affinity bounding boxes provide an absurdly redundant FIVE rotation handles! One of them already has a different visual treatment: the 'lollypop' handle. Give that handle a practical and useful difference: Enable it to rotate the bounding box around the selection when a modifier key is pressed, thereby enabling the illustrator to 'aim' the transform handles in whatever direction needed, relative to the selection.
JET

??
So that the path, after being rotated, would thereafter be considered un-rotated in its new orientation, in order to perform horizontal / vertical scaling and have its width and height values reset, etc. See the Reset Bounding Box command in Adobe Illustrator, or the transformed vs. un-transformed value options in Deneba Canvas. Resetting a bounding box is a very commonly needed function.
 
In Affinity, the width and height fields in the Transform panel continue to display the un-rotated width and height values even when the Reset Selection Box button is active.
 
JET

Not trying to argue, Tony, but then what is the intent of the Reset Selection Box button, and what is the practical use of the unpredictably skewed Selection Box which results from using it? This is very odd behavior, and I can't believe the majority of users won't regard it as such. Unless I'm just missing the intent of the behavior, I'd say it constitutes a bug.
 
JET

Exactly. In plain language for graphics people who have yet to get their feet wet in scripting:
JavaScript is the language used to script in, for example, Adobe Illustrator. JavaScript is not difficult for non-programmers to learn, and is ubiquitous. But much of what you can accomplish with JavaScript in Illustrator relies on Adobe's so-called ExtendScript (Adobe's 'extension' to JavaScript) and ScriptUI. These effectively provide the scripting user a set of 'pre-built' JavaScript constructs and objects that are specific to Adobe applications. Things like:
Modal dialogs that you can include in your scripts to appear within the program to, for example, prompt the user of your script to do something, like input desired values or select specific result options. Non-modal interactive 'control panels' that you can include in your scripts to remain visible within Illustrator while the user works with the script to, for example, try, preview, and change the result while the script is running, before committing it. A thorough (and thoroughly documented) Object Model that is a 'library' of Illustrator-specific constructs and their properties and methods. Those are the things that make application-specific scripting far more than just a glorified 'macro' for automating repetitive tasks like exporting files or executing a series of standard commands. They effectively inform the scripting language (JavaScript) of the 'under-the-hood' (i.e., under-the-interface) details of the program. They effectively empower you, the user, to create custom functions and features way beyond the standard feature set of the program. Just one example, for clarity:
One of my earliest Illustrator JavaScripts (well over a decade ago; maybe two?) is for drawing geometrically correct vector spheres at any desired orientation in a matter of seconds. When launched, the script presents a series of user prompts asking for the desired number of latitude and longitude lines and the angle at which the pole of the sphere is tilted.
I still use that script to this day (along with a considerable collection of others). Those are the kinds of things I am interested in scripting in Affinity Designer—adding full-blown drawing features to the program for things that it can't do in its standard feature set—as opposed to just 'recording' and 'playing back' a series of existing commands. (Realize, Adobe applications have had that, too—long before they had their JavaScript implementation—in the form of their so-called 'Actions' feature.)
I seriously hope the currently underway development of scripting support for Affinity includes full focus on a comprehensive application-specific object model and clear, thorough reference documentation of it upon its initial release.
JET

Having just downloaded the 2.4.0.2301 update, the first thing I've done is rush to check again the behavior of this feature, which—to me—is the most important of all in the new beta. I'm still somewhat disappointed:
Unless I'm missing something, if I…
Select multiple objects, one of which is a diagonally-oriented (relative to the page) simple, straight path drawn with the Pen. Set that straight path as the Key Object. Select_Set Selection Box. …then the bounding boxes of the objects other than the straight path do not re-orient to that of the straight path. Instead, they seem to either re-orient to one of the selected but non-key objects, or sometimes even become skewed bounding boxes.
First off, there is nothing intuitive about this behavior. Moreover, it wrecks what is, for my purposes, the greatest potential of a feature that (at long last) enables us to re-orient the scale handles independently of the current orientation of the content of the bounding box.
Set Selection Box should work the same way when the Key Object is an open straight path created with the Pen, as when any other object is the Key Object.
One of the first things mentioned in the initial announcement of this feature is isometric drawing. Well, a very basic principle of axonometric drawing (not just isometric) is that the minor diameter of any ellipse (that is a projection of a tilted circle) is always parallel to its 'thrust line' (the 'axis' that the ellipse 'orbits'). Failure to do that is the 'dead giveaway' of one of the most common errors in technical illustration. It instantly 'jumps off the page' and 'hurts the eyes' of an experienced technical illustrator.
But here's the thing: That principle of circles always being foreshortened in the direction parallel to their 'thrust lines' does not just apply to circles. It applies to literally any planar shape(s). Whole labels. Whole floorplans. Everything.
We need to be able to do this:
Draw something 'in-the-flat', no matter how simple or elaborate. Draw a simple, single-segment, straight path in any diagonal direction (the 'thrust line' that is perpendicular to the plane of the object(s) about to be scaled). (We should not have to use a box or anything other than a straight path, just to serve as a scale direction). Rotate the bounding box(es) of the objects to be scaled without rotating their contents, thereby snapping the scale handles into parallel with the 'thrust line'. Deselect the 'thrust line'. Scale the other selected objects in the direction parallel to the 'thrust line'. It should be obvious that the need to simply draw a simple straight path in any required direction and have it serve as the 'thrust line' is essential (and intuitive).
That feature, if implemented as described, would be something that to my knowledge does not exist in competing mainstream 2D general-purpose vector drawing programs.
But here's the other thing: I don't see why the interface for this can't be more intuitive and more elegant:
Simply provide a momentary keyboard shortcut that, when dragging the 'lollypop' bounding box rotation handle, causes the bounding box to rotate without rotating its content. And make that rotation aware of active Snap settings. Seems to me, that would be more direct and intuitively discoverable than the menu selections, and on-page tactile instead of just tucked away in a menu.
Lest anyone think this is only about mechanically-correct tech drawing…it's not. Example:
Suppose I'm not just a tech illustrator, but also a caricaturist. Everyone knows that every time Pinocchijoe opens his mouth, his nose grows. So suppose I've drawn a series of cartoon frames in which Pinocchijoe is looking up at the sky, down at his feet, for the nearest stage exit, etc. I need to increasingly stretch his nose in the corresponding direction in which he's looking in each subsequent frame. So I simply:
Select the object(s) that comprise his nose Set the transform anchor at the base of his nose mousedown on the lollypop, press the keyboard modifier, and rotate the bounding box around its content mousedown on the now correctly-oriented scale handle and drag it to scale the selection in the needed direction What am I missing here?
JET

I whole-heartedly agree with your comment re FreeHand. But even in that context, this is still true:
One of the huge advantages of FreeHand was its direct and convenient provision for drawing in 'hairline' mode; wherein paths are displayed at the smallest stroke width, regardless of zoom. Greatly enhanced accuracy confidence, and was my default mode whenever drawing Bezier paths. Illustrator's 'Outline Mode' (or whatever it's called; don't remember for sure, and don't have Illustrator installed on this laptop)—is a poor substitute. As a tedious workaround, I always draw paths in Illustrator using the .25 pt. stroke width, and apply Styles thereafter. Pain in the neck, which can be said of many many things in Illustrator compared to FreeHand.
So, yeah, something needs to be re-worked in the doubleClick to switch tools. Its being dependent upon clicking a path's stroke width versus its path is not good interface design.
Even given that, we FreeHand users recall that It never needed two selection tools, and only added a mimic of Illustrator's so-called 'Direct Selection Tool' as a conciliatory move for Illustrator-habituated users too impatient to come to understand that FreeHand's single Selection Tool was far more efficient than Illustrator's three separate path manipulation tools (the third being the stupid 'Convert Anchor Point Tool'). It was not until the very last version of FreeHand that the 'white pointer'—as we called it—was even given a single (and still insignificant) function that couldn't be done with the single 'black pointer.'
Well-versed FreeHand users have yet to see any Bezier drawing program that matches FreeHand's interface elegance.
JET

Exactly. In plain language for graphics people who have yet to get their feet wet in scripting:
JavaScript is the language used to script in, for example, Adobe Illustrator. JavaScript is not difficult for non-programmers to learn, and is ubiquitous. But much of what you can accomplish with JavaScript in Illustrator relies on Adobe's so-called ExtendScript (Adobe's 'extension' to JavaScript) and ScriptUI. These effectively provide the scripting user a set of 'pre-built' JavaScript constructs and objects that are specific to Adobe applications. Things like:
Modal dialogs that you can include in your scripts to appear within the program to, for example, prompt the user of your script to do something, like input desired values or select specific result options. Non-modal interactive 'control panels' that you can include in your scripts to remain visible within Illustrator while the user works with the script to, for example, try, preview, and change the result while the script is running, before committing it. A thorough (and thoroughly documented) Object Model that is a 'library' of Illustrator-specific constructs and their properties and methods. Those are the things that make application-specific scripting far more than just a glorified 'macro' for automating repetitive tasks like exporting files or executing a series of standard commands. They effectively inform the scripting language (JavaScript) of the 'under-the-hood' (i.e., under-the-interface) details of the program. They effectively empower you, the user, to create custom functions and features way beyond the standard feature set of the program. Just one example, for clarity:
One of my earliest Illustrator JavaScripts (well over a decade ago; maybe two?) is for drawing geometrically correct vector spheres at any desired orientation in a matter of seconds. When launched, the script presents a series of user prompts asking for the desired number of latitude and longitude lines and the angle at which the pole of the sphere is tilted.
I still use that script to this day (along with a considerable collection of others). Those are the kinds of things I am interested in scripting in Affinity Designer—adding full-blown drawing features to the program for things that it can't do in its standard feature set—as opposed to just 'recording' and 'playing back' a series of existing commands. (Realize, Adobe applications have had that, too—long before they had their JavaScript implementation—in the form of their so-called 'Actions' feature.)
I seriously hope the currently underway development of scripting support for Affinity includes full focus on a comprehensive application-specific object model and clear, thorough reference documentation of it upon its initial release.
JET

Well depends on how you interpret "outside affinity", or "run outside affinity". Application specific scripting (in some choosen scripting language) is usually performed against an by an application provided programming API, where in turn (the API itself) is tighly coupled to the application and thus offers access to certain available made internal functions/methods offered by the application. The scripting implementation (in some choosen language/dialect) then uses that application API, together with possible other third-party scripting language based modules/APIs, in order to perform certain operations in the context of the application it is meant for.
Many functionality wise things (automation etc.) do highly depend on what an corresponding app API offers to be accessed and reused here, also how the scripting context itself then is intended to be executed, aka if just from inside of an running app, or more flexible from outside without the need of the app itself to be running etc.
 

If you hit the segment line (path) of the stroke (shown with the blue line), it will add a node but if you hit the green part of the stroke in this screenshot it will toggle tools. The problem of course is that not all paths have enough stroke area to differentiate the target.

I love this feature. Reminds me of Freehand and anything that takes us closer to Freehand is great!

Well, I, for one, am not.
No one applauds what Serif is doing more than I. But I will never pay extorsive subscription fees for mission-critical software, effectively surrendering my own work as hostage to the vendor.
It's not a matter of 'being able to afford it'. It's a matter of principle. I maintained my (not cheap) perpetual license to Adobe's Master Collection from its initial release until the day Adobe foisted its Captive Creator licensing scheme upon its decades-long users. That very day was full-stop. I immediately initiated my own methodical plan for eliminating dependence upon Adobe, which has not received one red cent from me since.
Indeed, the very marketing myth 'promise' of subscription-based software fees is that it's 'more affordable' to 'starving artists' than the lump sum payment of a perpetual license. It's the same age-old scam of saying renting a roof over your head is 'cheaper' than owning it.
I'm sure Serif is profitable and knows quite well what it's doing. A large part of what Serif is doing is the long-overdue embodiment of competition: providing dramatically higher price/function value in a market segment that has been artificially overpriced for ages.
2D bezier based drawing is not rocket science anymore. Adobe and its ilk still cling desperately to the antiquated price structure of long-gone days when a 3-color letter-size inkjet printer cost ten times what far more capable machines go for now, even despite decades of inflation.
Serif is developing its products at its methodical rate, with a much-appreciated eye toward innovation; not just implementing tit-for-tat, copycat, me, too, same-old features.
Learn to exploit what it provides. Workaround what is not yet implemented. Provide at least marginal originality in feedback.
JET

Well, I, for one, am not.
No one applauds what Serif is doing more than I. But I will never pay extorsive subscription fees for mission-critical software, effectively surrendering my own work as hostage to the vendor.
It's not a matter of 'being able to afford it'. It's a matter of principle. I maintained my (not cheap) perpetual license to Adobe's Master Collection from its initial release until the day Adobe foisted its Captive Creator licensing scheme upon its decades-long users. That very day was full-stop. I immediately initiated my own methodical plan for eliminating dependence upon Adobe, which has not received one red cent from me since.
Indeed, the very marketing myth 'promise' of subscription-based software fees is that it's 'more affordable' to 'starving artists' than the lump sum payment of a perpetual license. It's the same age-old scam of saying renting a roof over your head is 'cheaper' than owning it.
I'm sure Serif is profitable and knows quite well what it's doing. A large part of what Serif is doing is the long-overdue embodiment of competition: providing dramatically higher price/function value in a market segment that has been artificially overpriced for ages.
2D bezier based drawing is not rocket science anymore. Adobe and its ilk still cling desperately to the antiquated price structure of long-gone days when a 3-color letter-size inkjet printer cost ten times what far more capable machines go for now, even despite decades of inflation.
Serif is developing its products at its methodical rate, with a much-appreciated eye toward innovation; not just implementing tit-for-tat, copycat, me, too, same-old features.
Learn to exploit what it provides. Workaround what is not yet implemented. Provide at least marginal originality in feedback.
JET

Well, I, for one, am not.
No one applauds what Serif is doing more than I. But I will never pay extorsive subscription fees for mission-critical software, effectively surrendering my own work as hostage to the vendor.
It's not a matter of 'being able to afford it'. It's a matter of principle. I maintained my (not cheap) perpetual license to Adobe's Master Collection from its initial release until the day Adobe foisted its Captive Creator licensing scheme upon its decades-long users. That very day was full-stop. I immediately initiated my own methodical plan for eliminating dependence upon Adobe, which has not received one red cent from me since.
Indeed, the very marketing myth 'promise' of subscription-based software fees is that it's 'more affordable' to 'starving artists' than the lump sum payment of a perpetual license. It's the same age-old scam of saying renting a roof over your head is 'cheaper' than owning it.
I'm sure Serif is profitable and knows quite well what it's doing. A large part of what Serif is doing is the long-overdue embodiment of competition: providing dramatically higher price/function value in a market segment that has been artificially overpriced for ages.
2D bezier based drawing is not rocket science anymore. Adobe and its ilk still cling desperately to the antiquated price structure of long-gone days when a 3-color letter-size inkjet printer cost ten times what far more capable machines go for now, even despite decades of inflation.
Serif is developing its products at its methodical rate, with a much-appreciated eye toward innovation; not just implementing tit-for-tat, copycat, me, too, same-old features.
Learn to exploit what it provides. Workaround what is not yet implemented. Provide at least marginal originality in feedback.
JET

Well, I, for one, am not.
No one applauds what Serif is doing more than I. But I will never pay extorsive subscription fees for mission-critical software, effectively surrendering my own work as hostage to the vendor.
It's not a matter of 'being able to afford it'. It's a matter of principle. I maintained my (not cheap) perpetual license to Adobe's Master Collection from its initial release until the day Adobe foisted its Captive Creator licensing scheme upon its decades-long users. That very day was full-stop. I immediately initiated my own methodical plan for eliminating dependence upon Adobe, which has not received one red cent from me since.
Indeed, the very marketing myth 'promise' of subscription-based software fees is that it's 'more affordable' to 'starving artists' than the lump sum payment of a perpetual license. It's the same age-old scam of saying renting a roof over your head is 'cheaper' than owning it.
I'm sure Serif is profitable and knows quite well what it's doing. A large part of what Serif is doing is the long-overdue embodiment of competition: providing dramatically higher price/function value in a market segment that has been artificially overpriced for ages.
2D bezier based drawing is not rocket science anymore. Adobe and its ilk still cling desperately to the antiquated price structure of long-gone days when a 3-color letter-size inkjet printer cost ten times what far more capable machines go for now, even despite decades of inflation.
Serif is developing its products at its methodical rate, with a much-appreciated eye toward innovation; not just implementing tit-for-tat, copycat, me, too, same-old features.
Learn to exploit what it provides. Workaround what is not yet implemented. Provide at least marginal originality in feedback.
JET

Well, I, for one, am not.
No one applauds what Serif is doing more than I. But I will never pay extorsive subscription fees for mission-critical software, effectively surrendering my own work as hostage to the vendor.
It's not a matter of 'being able to afford it'. It's a matter of principle. I maintained my (not cheap) perpetual license to Adobe's Master Collection from its initial release until the day Adobe foisted its Captive Creator licensing scheme upon its decades-long users. That very day was full-stop. I immediately initiated my own methodical plan for eliminating dependence upon Adobe, which has not received one red cent from me since.
Indeed, the very marketing myth 'promise' of subscription-based software fees is that it's 'more affordable' to 'starving artists' than the lump sum payment of a perpetual license. It's the same age-old scam of saying renting a roof over your head is 'cheaper' than owning it.
I'm sure Serif is profitable and knows quite well what it's doing. A large part of what Serif is doing is the long-overdue embodiment of competition: providing dramatically higher price/function value in a market segment that has been artificially overpriced for ages.
2D bezier based drawing is not rocket science anymore. Adobe and its ilk still cling desperately to the antiquated price structure of long-gone days when a 3-color letter-size inkjet printer cost ten times what far more capable machines go for now, even despite decades of inflation.
Serif is developing its products at its methodical rate, with a much-appreciated eye toward innovation; not just implementing tit-for-tat, copycat, me, too, same-old features.
Learn to exploit what it provides. Workaround what is not yet implemented. Provide at least marginal originality in feedback.
JET

I am not sure whether that is true any more.
I see in the Resolve Forums many moving from Adobe.
I think it is true that the hobby, semi pro and some pro's are moving to the "cheap" options. However, many professionals (never mind the rest) simply don't want the Adobe Subscription model. 
 

Why won't Adobe listen to customer needs and develop a non-subscription version of its software?
 

"…but not if you press shift"
So?? It doesn't scale if you press Ctrl {Windows} either. But without pressing a modifier key it both scales and rotates in one move. So how would "scale" be a more appropriate name than "transform"?
Look; I'm all for intuitive and consistent terminology. And I've been at this for a while, too. I cut my vector-drawing teeth in Altsys Fontographer—the progenitor of FreeHand, before Illustrator even existed—on a Mac Plus. But egads, man, there's no real issue in this instance. Dear departed Aunt Mollie would call this "straining at a gnat to swallow an elephant".
For a real interface terminology issue, look no further than the current abuse of the "Pages" (or Artboards) and "Layers" terms. What is intuitive about starting a new document which displays a working area that certainly looks like a  page, drawing an ellipse on that 'non-page', and having the ellipse immediately listed in a Panel named "Layers" in which there are no Layers (or Pages)? Since when is a single ellipse a 'Layer'? This is supposed to be intuitive terminology convention? But we should take issue with "Point Transform Tool"?
Illustrator is historically one of the worst about needlessly renaming its so often late-to-the-game constructs and features that existed long before in competing programs. Calling pages 'artboards' and nodes 'anchor points'. Its utterly needless and wordy 'Convert Anchor Point Tool'. Starting the whole now pandemic 'necessity' for two primary selection tools—the second of which is awkwardly named the 'Direct Selection Tool'—when FreeHand's elegant single selection tool performed all the functionality of both, more efficiently, intuitively, and capably. Adobe should hardly be considered the authoritative preferred 'dictionary' for best feature naming.
So yes, I quite agree that words mean things. But functionality still trumps. The functionality of the Point Transform Tool addresses crucial omissions that stem from having only bounding box handles for common transformations: being able to rotate paths by their nodes, so as to intuitively snap them to paths and nodes already drawn. Before the Point Transform Tool, that was a serious failing relative to Illustrator. It's actually a bit of a new wrinkle and more elegant and accurate than the corresponding functionality in Illustrator.
Pen Tool: Draw three arbitrarily-shaped open paths; one near the upper left corner of the page; one near the lower right; and one in the middle. Your goal is to scale and orient the middle path—without distorting its shape—to perfectly fit between two arbitrary nodes; one on the upper left path and one on the lower right path. Point Transform Tool: Select the middle path. Mousedown on one endNode of the middle path. Drag and snap it to the target node on the upper left path. Drag the Transform Center and snap it to that same node. Mousedown on the other endNode of the middle path. Drag and snap it to the target node on the lower right path. Done. Tell me how you would do that as quickly and intuitively in Illustrator with one tool. "…do we need a [term like] 'Point Transform Tool' that…makes little semantic sense to most people?"
Yes! We need different terms for interface elements that are significantly different treatments of similar functionality in other programs, so that we know they're not just another re-packaged 'me, too' identical copycat treatment of same-old market-dominating (and progress stifling) programs like Illustrator.
I cringe every time I see users in forums like this demand "We must have a [insert Illustrator's term] tool in Affinity!", as if Illustrator's cluttered, confused, scattered, and often mediocre treatment is the ultimate de facto thing to emulate. Affinity is opportunity to finally advance 2D bezier drawing beyond the mediocrity of Illustrator. But it won't get there by just thoughtlessly demanding identical treatment from such long-in-the-tooth programs without putting at least a little thought toward how it might be done better.
 

"…but not if you press shift"
So?? It doesn't scale if you press Ctrl {Windows} either. But without pressing a modifier key it both scales and rotates in one move. So how would "scale" be a more appropriate name than "transform"?
Look; I'm all for intuitive and consistent terminology. And I've been at this for a while, too. I cut my vector-drawing teeth in Altsys Fontographer—the progenitor of FreeHand, before Illustrator even existed—on a Mac Plus. But egads, man, there's no real issue in this instance. Dear departed Aunt Mollie would call this "straining at a gnat to swallow an elephant".
For a real interface terminology issue, look no further than the current abuse of the "Pages" (or Artboards) and "Layers" terms. What is intuitive about starting a new document which displays a working area that certainly looks like a  page, drawing an ellipse on that 'non-page', and having the ellipse immediately listed in a Panel named "Layers" in which there are no Layers (or Pages)? Since when is a single ellipse a 'Layer'? This is supposed to be intuitive terminology convention? But we should take issue with "Point Transform Tool"?
Illustrator is historically one of the worst about needlessly renaming its so often late-to-the-game constructs and features that existed long before in competing programs. Calling pages 'artboards' and nodes 'anchor points'. Its utterly needless and wordy 'Convert Anchor Point Tool'. Starting the whole now pandemic 'necessity' for two primary selection tools—the second of which is awkwardly named the 'Direct Selection Tool'—when FreeHand's elegant single selection tool performed all the functionality of both, more efficiently, intuitively, and capably. Adobe should hardly be considered the authoritative preferred 'dictionary' for best feature naming.
So yes, I quite agree that words mean things. But functionality still trumps. The functionality of the Point Transform Tool addresses crucial omissions that stem from having only bounding box handles for common transformations: being able to rotate paths by their nodes, so as to intuitively snap them to paths and nodes already drawn. Before the Point Transform Tool, that was a serious failing relative to Illustrator. It's actually a bit of a new wrinkle and more elegant and accurate than the corresponding functionality in Illustrator.
Pen Tool: Draw three arbitrarily-shaped open paths; one near the upper left corner of the page; one near the lower right; and one in the middle. Your goal is to scale and orient the middle path—without distorting its shape—to perfectly fit between two arbitrary nodes; one on the upper left path and one on the lower right path. Point Transform Tool: Select the middle path. Mousedown on one endNode of the middle path. Drag and snap it to the target node on the upper left path. Drag the Transform Center and snap it to that same node. Mousedown on the other endNode of the middle path. Drag and snap it to the target node on the lower right path. Done. Tell me how you would do that as quickly and intuitively in Illustrator with one tool. "…do we need a [term like] 'Point Transform Tool' that…makes little semantic sense to most people?"
Yes! We need different terms for interface elements that are significantly different treatments of similar functionality in other programs, so that we know they're not just another re-packaged 'me, too' identical copycat treatment of same-old market-dominating (and progress stifling) programs like Illustrator.
I cringe every time I see users in forums like this demand "We must have a [insert Illustrator's term] tool in Affinity!", as if Illustrator's cluttered, confused, scattered, and often mediocre treatment is the ultimate de facto thing to emulate. Affinity is opportunity to finally advance 2D bezier drawing beyond the mediocrity of Illustrator. But it won't get there by just thoughtlessly demanding identical treatment from such long-in-the-tooth programs without putting at least a little thought toward how it might be done better.
 

"…but not if you press shift"
So?? It doesn't scale if you press Ctrl {Windows} either. But without pressing a modifier key it both scales and rotates in one move. So how would "scale" be a more appropriate name than "transform"?
Look; I'm all for intuitive and consistent terminology. And I've been at this for a while, too. I cut my vector-drawing teeth in Altsys Fontographer—the progenitor of FreeHand, before Illustrator even existed—on a Mac Plus. But egads, man, there's no real issue in this instance. Dear departed Aunt Mollie would call this "straining at a gnat to swallow an elephant".
For a real interface terminology issue, look no further than the current abuse of the "Pages" (or Artboards) and "Layers" terms. What is intuitive about starting a new document which displays a working area that certainly looks like a  page, drawing an ellipse on that 'non-page', and having the ellipse immediately listed in a Panel named "Layers" in which there are no Layers (or Pages)? Since when is a single ellipse a 'Layer'? This is supposed to be intuitive terminology convention? But we should take issue with "Point Transform Tool"?
Illustrator is historically one of the worst about needlessly renaming its so often late-to-the-game constructs and features that existed long before in competing programs. Calling pages 'artboards' and nodes 'anchor points'. Its utterly needless and wordy 'Convert Anchor Point Tool'. Starting the whole now pandemic 'necessity' for two primary selection tools—the second of which is awkwardly named the 'Direct Selection Tool'—when FreeHand's elegant single selection tool performed all the functionality of both, more efficiently, intuitively, and capably. Adobe should hardly be considered the authoritative preferred 'dictionary' for best feature naming.
So yes, I quite agree that words mean things. But functionality still trumps. The functionality of the Point Transform Tool addresses crucial omissions that stem from having only bounding box handles for common transformations: being able to rotate paths by their nodes, so as to intuitively snap them to paths and nodes already drawn. Before the Point Transform Tool, that was a serious failing relative to Illustrator. It's actually a bit of a new wrinkle and more elegant and accurate than the corresponding functionality in Illustrator.
Pen Tool: Draw three arbitrarily-shaped open paths; one near the upper left corner of the page; one near the lower right; and one in the middle. Your goal is to scale and orient the middle path—without distorting its shape—to perfectly fit between two arbitrary nodes; one on the upper left path and one on the lower right path. Point Transform Tool: Select the middle path. Mousedown on one endNode of the middle path. Drag and snap it to the target node on the upper left path. Drag the Transform Center and snap it to that same node. Mousedown on the other endNode of the middle path. Drag and snap it to the target node on the lower right path. Done. Tell me how you would do that as quickly and intuitively in Illustrator with one tool. "…do we need a [term like] 'Point Transform Tool' that…makes little semantic sense to most people?"
Yes! We need different terms for interface elements that are significantly different treatments of similar functionality in other programs, so that we know they're not just another re-packaged 'me, too' identical copycat treatment of same-old market-dominating (and progress stifling) programs like Illustrator.
I cringe every time I see users in forums like this demand "We must have a [insert Illustrator's term] tool in Affinity!", as if Illustrator's cluttered, confused, scattered, and often mediocre treatment is the ultimate de facto thing to emulate. Affinity is opportunity to finally advance 2D bezier drawing beyond the mediocrity of Illustrator. But it won't get there by just thoughtlessly demanding identical treatment from such long-in-the-tooth programs without putting at least a little thought toward how it might be done better.
 

Also translates (aka moves) objects.
Translate, scale and rotate are transforms. The name of the tool seems appropriate.