JET_Affinity

Nonsense. Since when is merely specifying a line by length and angle or drawing to user-defined scale only for 'CAD tools'? Egads, man, by that kind of logic, no 'CAD tool' should be able to colorize a vector object, either. Do you know why it's called a Bezier curve, and what industry Mr. Bezier was working in?
Mainstream vector drawing programs are very general-purpose. They are not just used for loosey-goosey freehand scribbling in an ill-conceived attempt to emulate 'natural media' on a tiny cell phone screen with a pudgy finger. These programs are routinely used for:
Cleaning up and augmenting CAD exports to make them suitable for commercial-quality reproduction Drawing die cuts for commercial collateral and package design Drawing garden plats Maps of all kinds Typeface design Bird's-eye views of theme parks for visitor's brochures Conceptuals and working drawings for commercial signage, storefronts, interior designs, point-of-sale displays, billboards Cutting paths for sign vinyl plotters and routers Architectural concepts Trade show displays and booth sites, both as conceptual renderings and as final working drawings All manner of info graphics And, yes, axonometric drawing (assembly diagrams for everything from colorful pre-school toys to mundane light fixtures) …I could go on indefinitely. Since the mid-80s I've been using FreeHand, Canvas, Draw, Illustrator, Flash, and most others that have come along in this software category since then to do these kinds of things, all of which are squarely within the real world domain of profitable commercial illustration.
JET
 

Regardless, the request for a hairline stroke weight setting is valid. (It's been brought up before in other threads.)
For those not familiar, a hairline stroke weight always renders at the smallest width possible on the output device, be it your monitor or an imagesetter. This is advantageous when drawing paths in detailed illustrations, during which we are constantly zooming in and out. Having stroke weight set to hairline feels more precise and is less distracting because the stroke weight is always drawn the same, regardless of zoom. The extreme zooming capabilities of Affinity as compared to other programs buttresses the point.
It's a great feature, a standard setting in PostScript, and it should be provided in every vector drawing software.
JET

It's also another "low hanging fruit" opportunity to surpass Illustrator. Throughout the FreeHand vs Illustrator competitive years, FreeHand users knew what a huge advantage it was to work with hairline strokes in the normal full-color interface. The only way to get hairline editing behavior in Illustrator is to put it in its lame Outline Mode.
JET

I’m not an admin but I dare to say what they would say: It’s done when it’s done.
What’s the point of asking when it’s done? Just continue to use Illustrator or whatever until you get the notice that it’s here. It’s not going to come any quicker by constantly asking.

Regardless, the request for a hairline stroke weight setting is valid. (It's been brought up before in other threads.)
For those not familiar, a hairline stroke weight always renders at the smallest width possible on the output device, be it your monitor or an imagesetter. This is advantageous when drawing paths in detailed illustrations, during which we are constantly zooming in and out. Having stroke weight set to hairline feels more precise and is less distracting because the stroke weight is always drawn the same, regardless of zoom. The extreme zooming capabilities of Affinity as compared to other programs buttresses the point.
It's a great feature, a standard setting in PostScript, and it should be provided in every vector drawing software.
JET

Even without a set of dimensioning tools, length and area of a selected path should be provided in the interface of any serious drawing program.
 
JET

For those not familiar:
Illustrator's awkwardly named Merge performs two basic Boolean operations in one move, based on their color:
It Unions touching (abutting or overlapping) fills of the same color. It Punches (subtracts) overlapping fills of different colors. (Frontmost punches others). So it results in the minimal individual paths around visually contiguous regions of the same color.
One common real-world use case for this is when preparing a design for cutting from sign vinyl. In that common workflow, you don't want any cuts across same-colored regions, because as the vinyl shrinks over time, void slivers appear. So the Merge command saves a lot of time and tedium.
However, it addresses just half of that use case: When different colors of a sign vinyl design need to appear to abut, one actually does need a small amount of overlap for the very same reason: It's very difficult to physically perfectly abut different-colored pieces of vinyl when applying it, and even if you could, the eventual shrinkage would again cause slivers between them.
The practical fix is analogous to that of color trapping (chokes, spreads, and overprinting) in print.
So this is yet another opportunity to improve upon an Illustrator feature by addressing its shortcomings instead of just mimicking it in 'me, too' fashion: Such a command should incorporate an Overlap setting that would default to zero, but could be set by the user whenever a trap (parallel to the shapes) is needed. That would address the tedium of having to manually apply Offset Path (in AI) or Contour (in Affinity) to the results of a Merge operation. In other words, the suggested new feature function should incorporate three basic operations (union, subtract, and offset), not just two (union and subtract).
Illustrator could have long since addressed this by providing a checkbox in its Merge command: Respect Manual Traps or Respect Overprinting Strokes. But it doesn't. And its 'Pathfinders' generally ignore strokes anyway. Expand Appearance 'sees' manual traps built in Illustrator, but treats them as 'third' colors instead of as the same color as the spread or choked color.
Another low-hanging-fruit opportunity to surpass Illustrator's functionality by avoiding its endemic characteristic of too many grab-bag standalone features being 'unaware' of each other.
JET

Macro, unlikely. Too many variables. Although Windows applications tend to refer to Visual Basic scripts as 'macros', generally speaking, a macro is just a recording of a sequence of individual performed operations or commands provided in the standard interface, like so-called Actions in Adobe apps. The sequence would likely be different for every piece of artwork, thereby negating the advantage.
Scripting, on the other hand, maybe. But that's far more ambitious. A good scripting implementation provides for variables and conditional logic. But the operative phrase here is "good implementation". I've resorted to writing Javascript to create a substantial collection of 'missing features' in Illustrator, and yes, I am one of those who dearly wants to see Affinity provide a complete and well-documented Javascript object model as soon as its feature set is more fully fleshed-out and stabilized. But even so, it was the continual frustration of scripting AI that I had to resort to it for no-brainer missing functionality like, for just one example, a simple reverse path command. (And no, no one need trot out clicking an endNode with the Pen Tool.)
But  it comes immediately to mind in this context that Illustrator's Javascript (as of CS6, after which I abandoned it because I will not enslave myself nor have my business-critical files held hostage to a software vendor) provides no method for collision detection between paths (something I asked for throughout the years of writing AI scripting). So one might be able to devise into the script a repetitive loop of 'tests' to determine which paths actually overlap. But I'd be gritting my teeth doing that just because the functionality should be in the standard interface.
The use case I described (vinyl cutting) is one in which something akin to Illustrator's Merge command quickly becomes indispensable. But its utility is certainly not limited to that. It's one of the kind of features that a user may not immediately recognize the 'need' for, but will quite likely find many uses for once it is provided. Adding a button and a slider to a Boolean palette would not constitute excessive gratuitous tool-glut.
If one thinks it through, it becomes evident that the so-called Merge Pathfinder is doing essentially much the same thing that the much later so-called Live Paint and Shape Builder features are doing. They're just doing it as a 'live effect' with an elaborate tool interface, instead of by a simple command. Much of Illustrator's tool glut boils down to 're-packaging' of existing functionality with more elaborate interfaces.
Of course it did. And I dare say, like many other things, it probably appeared before Illustrator's trapping functions. But FreeHand did not have a command akin to the one specified in this thread. The Merge command was one of the precious few positives in having to segue to AI after Adobe bought and killed FreeHand.
I'd have to fire up the old bulbous pinstripe Mac G4 relic to verify, but something in my own vague recollection suggests that FreeHand's Boolean path operations could be made to incorporate manually-built traps.
All this is why I continually argue that we need to think beyond Illustrator. Illustrator is just one of the old 'Big Four" (FreeHand, Illustrator, CorelDRAW, Canvas). A lot of redundant clutter lingers from the ad-hoc development since those days and elegance is lost when new offerings just 'copy what [historically] sells.' Elegance is achieved by providing fully thought-through and integrated functional power just beneath a clean, minimalist, but intuitive interface. The clutter of the older apps is nowadays nothing to emulate.
My favorite example of the 'everybody now does it, so it must be right' fallacy is the now omnipresent confused, always-shifting, schizophrenic  'Bar' that can't decided whether it's a Tools Option Bar or a Commands Bar. Every graphics software developer should be required to understand and experience the advantage of FreeHand's incomparable Inspector Palette. (Closest thing to it in any program I use is in the Layout Mode of FileMaker Pro; a database program, of all things.)
JET

For those not familiar:
Illustrator's awkwardly named Merge performs two basic Boolean operations in one move, based on their color:
It Unions touching (abutting or overlapping) fills of the same color. It Punches (subtracts) overlapping fills of different colors. (Frontmost punches others). So it results in the minimal individual paths around visually contiguous regions of the same color.
One common real-world use case for this is when preparing a design for cutting from sign vinyl. In that common workflow, you don't want any cuts across same-colored regions, because as the vinyl shrinks over time, void slivers appear. So the Merge command saves a lot of time and tedium.
However, it addresses just half of that use case: When different colors of a sign vinyl design need to appear to abut, one actually does need a small amount of overlap for the very same reason: It's very difficult to physically perfectly abut different-colored pieces of vinyl when applying it, and even if you could, the eventual shrinkage would again cause slivers between them.
The practical fix is analogous to that of color trapping (chokes, spreads, and overprinting) in print.
So this is yet another opportunity to improve upon an Illustrator feature by addressing its shortcomings instead of just mimicking it in 'me, too' fashion: Such a command should incorporate an Overlap setting that would default to zero, but could be set by the user whenever a trap (parallel to the shapes) is needed. That would address the tedium of having to manually apply Offset Path (in AI) or Contour (in Affinity) to the results of a Merge operation. In other words, the suggested new feature function should incorporate three basic operations (union, subtract, and offset), not just two (union and subtract).
Illustrator could have long since addressed this by providing a checkbox in its Merge command: Respect Manual Traps or Respect Overprinting Strokes. But it doesn't. And its 'Pathfinders' generally ignore strokes anyway. Expand Appearance 'sees' manual traps built in Illustrator, but treats them as 'third' colors instead of as the same color as the spread or choked color.
Another low-hanging-fruit opportunity to surpass Illustrator's functionality by avoiding its endemic characteristic of too many grab-bag standalone features being 'unaware' of each other.
JET

For those not familiar:
Illustrator's awkwardly named Merge performs two basic Boolean operations in one move, based on their color:
It Unions touching (abutting or overlapping) fills of the same color. It Punches (subtracts) overlapping fills of different colors. (Frontmost punches others). So it results in the minimal individual paths around visually contiguous regions of the same color.
One common real-world use case for this is when preparing a design for cutting from sign vinyl. In that common workflow, you don't want any cuts across same-colored regions, because as the vinyl shrinks over time, void slivers appear. So the Merge command saves a lot of time and tedium.
However, it addresses just half of that use case: When different colors of a sign vinyl design need to appear to abut, one actually does need a small amount of overlap for the very same reason: It's very difficult to physically perfectly abut different-colored pieces of vinyl when applying it, and even if you could, the eventual shrinkage would again cause slivers between them.
The practical fix is analogous to that of color trapping (chokes, spreads, and overprinting) in print.
So this is yet another opportunity to improve upon an Illustrator feature by addressing its shortcomings instead of just mimicking it in 'me, too' fashion: Such a command should incorporate an Overlap setting that would default to zero, but could be set by the user whenever a trap (parallel to the shapes) is needed. That would address the tedium of having to manually apply Offset Path (in AI) or Contour (in Affinity) to the results of a Merge operation. In other words, the suggested new feature function should incorporate three basic operations (union, subtract, and offset), not just two (union and subtract).
Illustrator could have long since addressed this by providing a checkbox in its Merge command: Respect Manual Traps or Respect Overprinting Strokes. But it doesn't. And its 'Pathfinders' generally ignore strokes anyway. Expand Appearance 'sees' manual traps built in Illustrator, but treats them as 'third' colors instead of as the same color as the spread or choked color.
Another low-hanging-fruit opportunity to surpass Illustrator's functionality by avoiding its endemic characteristic of too many grab-bag standalone features being 'unaware' of each other.
JET

For those not familiar:
Illustrator's awkwardly named Merge performs two basic Boolean operations in one move, based on their color:
It Unions touching (abutting or overlapping) fills of the same color. It Punches (subtracts) overlapping fills of different colors. (Frontmost punches others). So it results in the minimal individual paths around visually contiguous regions of the same color.
One common real-world use case for this is when preparing a design for cutting from sign vinyl. In that common workflow, you don't want any cuts across same-colored regions, because as the vinyl shrinks over time, void slivers appear. So the Merge command saves a lot of time and tedium.
However, it addresses just half of that use case: When different colors of a sign vinyl design need to appear to abut, one actually does need a small amount of overlap for the very same reason: It's very difficult to physically perfectly abut different-colored pieces of vinyl when applying it, and even if you could, the eventual shrinkage would again cause slivers between them.
The practical fix is analogous to that of color trapping (chokes, spreads, and overprinting) in print.
So this is yet another opportunity to improve upon an Illustrator feature by addressing its shortcomings instead of just mimicking it in 'me, too' fashion: Such a command should incorporate an Overlap setting that would default to zero, but could be set by the user whenever a trap (parallel to the shapes) is needed. That would address the tedium of having to manually apply Offset Path (in AI) or Contour (in Affinity) to the results of a Merge operation. In other words, the suggested new feature function should incorporate three basic operations (union, subtract, and offset), not just two (union and subtract).
Illustrator could have long since addressed this by providing a checkbox in its Merge command: Respect Manual Traps or Respect Overprinting Strokes. But it doesn't. And its 'Pathfinders' generally ignore strokes anyway. Expand Appearance 'sees' manual traps built in Illustrator, but treats them as 'third' colors instead of as the same color as the spread or choked color.
Another low-hanging-fruit opportunity to surpass Illustrator's functionality by avoiding its endemic characteristic of too many grab-bag standalone features being 'unaware' of each other.
JET

For those not familiar:
Illustrator's awkwardly named Merge performs two basic Boolean operations in one move, based on their color:
It Unions touching (abutting or overlapping) fills of the same color. It Punches (subtracts) overlapping fills of different colors. (Frontmost punches others). So it results in the minimal individual paths around visually contiguous regions of the same color.
One common real-world use case for this is when preparing a design for cutting from sign vinyl. In that common workflow, you don't want any cuts across same-colored regions, because as the vinyl shrinks over time, void slivers appear. So the Merge command saves a lot of time and tedium.
However, it addresses just half of that use case: When different colors of a sign vinyl design need to appear to abut, one actually does need a small amount of overlap for the very same reason: It's very difficult to physically perfectly abut different-colored pieces of vinyl when applying it, and even if you could, the eventual shrinkage would again cause slivers between them.
The practical fix is analogous to that of color trapping (chokes, spreads, and overprinting) in print.
So this is yet another opportunity to improve upon an Illustrator feature by addressing its shortcomings instead of just mimicking it in 'me, too' fashion: Such a command should incorporate an Overlap setting that would default to zero, but could be set by the user whenever a trap (parallel to the shapes) is needed. That would address the tedium of having to manually apply Offset Path (in AI) or Contour (in Affinity) to the results of a Merge operation. In other words, the suggested new feature function should incorporate three basic operations (union, subtract, and offset), not just two (union and subtract).
Illustrator could have long since addressed this by providing a checkbox in its Merge command: Respect Manual Traps or Respect Overprinting Strokes. But it doesn't. And its 'Pathfinders' generally ignore strokes anyway. Expand Appearance 'sees' manual traps built in Illustrator, but treats them as 'third' colors instead of as the same color as the spread or choked color.
Another low-hanging-fruit opportunity to surpass Illustrator's functionality by avoiding its endemic characteristic of too many grab-bag standalone features being 'unaware' of each other.
JET

For those not familiar:
Illustrator's awkwardly named Merge performs two basic Boolean operations in one move, based on their color:
It Unions touching (abutting or overlapping) fills of the same color. It Punches (subtracts) overlapping fills of different colors. (Frontmost punches others). So it results in the minimal individual paths around visually contiguous regions of the same color.
One common real-world use case for this is when preparing a design for cutting from sign vinyl. In that common workflow, you don't want any cuts across same-colored regions, because as the vinyl shrinks over time, void slivers appear. So the Merge command saves a lot of time and tedium.
However, it addresses just half of that use case: When different colors of a sign vinyl design need to appear to abut, one actually does need a small amount of overlap for the very same reason: It's very difficult to physically perfectly abut different-colored pieces of vinyl when applying it, and even if you could, the eventual shrinkage would again cause slivers between them.
The practical fix is analogous to that of color trapping (chokes, spreads, and overprinting) in print.
So this is yet another opportunity to improve upon an Illustrator feature by addressing its shortcomings instead of just mimicking it in 'me, too' fashion: Such a command should incorporate an Overlap setting that would default to zero, but could be set by the user whenever a trap (parallel to the shapes) is needed. That would address the tedium of having to manually apply Offset Path (in AI) or Contour (in Affinity) to the results of a Merge operation. In other words, the suggested new feature function should incorporate three basic operations (union, subtract, and offset), not just two (union and subtract).
Illustrator could have long since addressed this by providing a checkbox in its Merge command: Respect Manual Traps or Respect Overprinting Strokes. But it doesn't. And its 'Pathfinders' generally ignore strokes anyway. Expand Appearance 'sees' manual traps built in Illustrator, but treats them as 'third' colors instead of as the same color as the spread or choked color.
Another low-hanging-fruit opportunity to surpass Illustrator's functionality by avoiding its endemic characteristic of too many grab-bag standalone features being 'unaware' of each other.
JET

For those not familiar:
Illustrator's awkwardly named Merge performs two basic Boolean operations in one move, based on their color:
It Unions touching (abutting or overlapping) fills of the same color. It Punches (subtracts) overlapping fills of different colors. (Frontmost punches others). So it results in the minimal individual paths around visually contiguous regions of the same color.
One common real-world use case for this is when preparing a design for cutting from sign vinyl. In that common workflow, you don't want any cuts across same-colored regions, because as the vinyl shrinks over time, void slivers appear. So the Merge command saves a lot of time and tedium.
However, it addresses just half of that use case: When different colors of a sign vinyl design need to appear to abut, one actually does need a small amount of overlap for the very same reason: It's very difficult to physically perfectly abut different-colored pieces of vinyl when applying it, and even if you could, the eventual shrinkage would again cause slivers between them.
The practical fix is analogous to that of color trapping (chokes, spreads, and overprinting) in print.
So this is yet another opportunity to improve upon an Illustrator feature by addressing its shortcomings instead of just mimicking it in 'me, too' fashion: Such a command should incorporate an Overlap setting that would default to zero, but could be set by the user whenever a trap (parallel to the shapes) is needed. That would address the tedium of having to manually apply Offset Path (in AI) or Contour (in Affinity) to the results of a Merge operation. In other words, the suggested new feature function should incorporate three basic operations (union, subtract, and offset), not just two (union and subtract).
Illustrator could have long since addressed this by providing a checkbox in its Merge command: Respect Manual Traps or Respect Overprinting Strokes. But it doesn't. And its 'Pathfinders' generally ignore strokes anyway. Expand Appearance 'sees' manual traps built in Illustrator, but treats them as 'third' colors instead of as the same color as the spread or choked color.
Another low-hanging-fruit opportunity to surpass Illustrator's functionality by avoiding its endemic characteristic of too many grab-bag standalone features being 'unaware' of each other.
JET

For clarity, I certainly hope no one is asking for this to be a default behavior.
I do not want an endNode of a path to auto-join to another path just because I drag it to within pick distance of another path's end. There are countless situations in illustration in which one draws coincident paths that should not be joined. Look no further than paths of different weights, color, or other style attributes that nonetheless need to have coincident ends. What about when more than two endNodes are coincident? How is the program supposed to know which path I would want it to auto-join to?
The auto-joining behavior of Adobe Illustrator's Pen, for example, is one of its most infuriatingly intrusive stumbling blocks. To avoid its infernal insistence on auto-joining to other deselected paths when drawing, you actually have to invoke this ridiculous override:
Mousedown somewhere that you don't want the next node to be Press and hold the spacebar Drag to where you do want it the node to be Mouseup Release the spacebar A path drawing tool is not a selection tool, and should not act like one. It has no business affecting unselected paths just because you need to place a node within pick distance of another path's endnode. Nor should it occur when just dragging an endNode.
At most, any such behavior should have to be invoked by a keyboard shortcut. It should not be default behavior.
The  task of cleaning up DXF files is an oft-cited use case, and one with which I am quite familiar, having been doing technical illustration since well before personal computers. But it's still a specifically vertical use case; nothing that should be cited to justify a default behavior. Other programs accommodate it with separate, explicitly-invoked menu commands. You select the paths you want to be affected and then invoke the joining command (with whatever parameters offered in a dialog). If that's what you're recommending, I'm fine with it. But auto-joining as default behavior is bad.
JET

For clarity, I certainly hope no one is asking for this to be a default behavior.
I do not want an endNode of a path to auto-join to another path just because I drag it to within pick distance of another path's end. There are countless situations in illustration in which one draws coincident paths that should not be joined. Look no further than paths of different weights, color, or other style attributes that nonetheless need to have coincident ends. What about when more than two endNodes are coincident? How is the program supposed to know which path I would want it to auto-join to?
The auto-joining behavior of Adobe Illustrator's Pen, for example, is one of its most infuriatingly intrusive stumbling blocks. To avoid its infernal insistence on auto-joining to other deselected paths when drawing, you actually have to invoke this ridiculous override:
Mousedown somewhere that you don't want the next node to be Press and hold the spacebar Drag to where you do want it the node to be Mouseup Release the spacebar A path drawing tool is not a selection tool, and should not act like one. It has no business affecting unselected paths just because you need to place a node within pick distance of another path's endnode. Nor should it occur when just dragging an endNode.
At most, any such behavior should have to be invoked by a keyboard shortcut. It should not be default behavior.
The  task of cleaning up DXF files is an oft-cited use case, and one with which I am quite familiar, having been doing technical illustration since well before personal computers. But it's still a specifically vertical use case; nothing that should be cited to justify a default behavior. Other programs accommodate it with separate, explicitly-invoked menu commands. You select the paths you want to be affected and then invoke the joining command (with whatever parameters offered in a dialog). If that's what you're recommending, I'm fine with it. But auto-joining as default behavior is bad.
JET

For clarity, I certainly hope no one is asking for this to be a default behavior.
I do not want an endNode of a path to auto-join to another path just because I drag it to within pick distance of another path's end. There are countless situations in illustration in which one draws coincident paths that should not be joined. Look no further than paths of different weights, color, or other style attributes that nonetheless need to have coincident ends. What about when more than two endNodes are coincident? How is the program supposed to know which path I would want it to auto-join to?
The auto-joining behavior of Adobe Illustrator's Pen, for example, is one of its most infuriatingly intrusive stumbling blocks. To avoid its infernal insistence on auto-joining to other deselected paths when drawing, you actually have to invoke this ridiculous override:
Mousedown somewhere that you don't want the next node to be Press and hold the spacebar Drag to where you do want it the node to be Mouseup Release the spacebar A path drawing tool is not a selection tool, and should not act like one. It has no business affecting unselected paths just because you need to place a node within pick distance of another path's endnode. Nor should it occur when just dragging an endNode.
At most, any such behavior should have to be invoked by a keyboard shortcut. It should not be default behavior.
The  task of cleaning up DXF files is an oft-cited use case, and one with which I am quite familiar, having been doing technical illustration since well before personal computers. But it's still a specifically vertical use case; nothing that should be cited to justify a default behavior. Other programs accommodate it with separate, explicitly-invoked menu commands. You select the paths you want to be affected and then invoke the joining command (with whatever parameters offered in a dialog). If that's what you're recommending, I'm fine with it. But auto-joining as default behavior is bad.
JET

So I am new to Affinity. 
I was an Adobe user and recently upgraded to the apple 2021 macbook.
I was using the Adobe CS6 suite to do all my design work and photo editing. When I got my new macbook I learned my pre-purchased Adobe CS6 did not support the new m1 chip so was facing the decision to pay a monthly Adobe subscription of $53(USD) per month forever! After 5 years, this would have amounted to $3180 (USD). That just seems so unreasonable to me because I feel I am 'priced out' of trying to design. 
Cue Affinity, the life-savers! 
Now that I've been using Affinity, Adobe couldn't pay me to switch back. Smart and thoughtful design + accessible honest pricing. It's also exciting to work with something new and robust like Affinity.
This is what design is all about.
 

Hi @PurpleFish,
referring to the duration of the discussion about a feature request is very common around here. I have learned over time that such a long discussion is an indication that Serif is aware of the topic (they do read this section of the forum and take notes). That Serif gave this feature a certain priority below all other features that have been published in the meantime (for unknown reasons). And I do assume that they have a very clear and realistic view of what they can and want to accomplish over time.
I believe this forum is the right place to express wishes for certain features and they are valid. It just doesn't work like a wishlist sent to Santa 😉
Cheers,
d.

I dont think its as much "taboo" as a horse beaten to its death long time ago. New stuff is being added every release and just because its not there yet doesn't mean will never be. Common sense - they cant add EVERYTHING we would like. I have some features I am hoping to be added too, some of them were just added ("select same..." - finally here). But what good does it make of repeating the same questions over and over and over again? Yeah, its not there, yeah its somewhere else... When its going to be? When they get to it. Its not like devs are just doing nothing, is it? Just because you consider it very important doesnt mean this has to be added as priority. You think they dont know that its not there? You think they just avoid subject because there is some conspiracy going on? They are busy working, making new Betas all the time, sharing, adding new stuff... Your favorite feature will surely be added at some point. You have to just deal with not knowing when exactly.

Some features are still missing, but I can assure you the app is still very much under development. It take times to develop something to be so stable and when people are paying money. Especially for the design community who are very critical of even simple changes. They are also writing for multiple platforms, which doesn't help when their team is limited. GIMP has been around for over 20 years, is open-source and so the comparison is not a good one.

Welcome to the Serif Affinity forums, HypoSim.
Yes, Designer is still being developed. All you have to do is look at the release notes for each of the releases, and you will see many major and minor enhancements have been made over that time period. You can find them here.
And the next release, 1.9, is in beta testing now with additional enhancements.
That does not mean that Serif will provide all the functions that everyone is asking for; they have their own plans and their own priorities.

Hello @ZachFB and welcome to the forum. Even if it looks it will be for only a short time reading your last statement.
It would have been a good practice to first search the forum to see if there is already a discussion about the features you are missing. Actually there are 🙂
This thread goes over (currently) 14 pages:
 
Here's a list of alternative solutions for tracing by forum member @v_kyr. So there's no urgent need to implement this feature in AD (even though I do not object the suggestion to have it implemented):
 
The same applies to vector blend:
I admit this is a technique that cannot be done in AD right now and there is no workaround for it. Unless you use a seperate software and import the result.
Apart from that, both, image trace and vector blend are in my opinion not 'most basic' features. But we do not have to discuss this since everyone has different priorities.
Good luck,
d.

Path blends have been a basic feature of Bezier drawing programs since the very early days. So I'm sure it will be added to Affinity. Blends are one of the primary ways to achieve accurately controlled shading in vector-based illustrations.
But once again; those only familiar with Illustrator need to understand that program is very often not the model to which to aspire. Illustrator's basic blend function has chronic problems which corresponding features in other programs don't; especially when it comes to blends on a spine path.
For one example, in Illustrator, the spacing of the interpolated objects is always affected by the curvature of the spine path. In other programs, the spacing is uniform along the length of the spine path, regardless of its  shape. Both are useful, but the latter is more commonly needed than the former. In Illustrator, to achieve what looks like uniform spacing requires the cumbersome workaround of adding a ridiculous number of nodes to the spine path. That, of course, negates much of the purpose of blends along a spine: the ability to adjust the shape of the spine while the blend is attached.
Both spacing methods should be provided and controlled by a an object-level setting (not application- or document-level preference). And a setting for progressive spacing should provide its own adjustment handles. That would be far more useful than just adjusting the spacing by moving the node curve handles of the spine.
Like many other things, though, a blend feature should be as thoroughly integrated with other features as possible. For example, to give credit where credit is due, Illustrator's blend feature works on stored Symbols used as key objects, not just single paths or groups of paths. That is both powerful and versatile. Moreover, it also works with the "higher construct" of instances of its 3D Effect. That is very powerful, enabling construction of things that would be very difficult to achieve otherwise.
In other words, a well-integrated blend feature should certainly be expected to blend between instances of higher constructs of the same type. For example, one would never logically expect a blend feature to blend between, say, a vector-based path and a raster image. That's functional nonsense. Likewise, one shouldn't expect it to "blend" a live Star object into a live Cylinder object, because those parametric objects have different setting attributes. But it should be expected to blend between multiple Star objects which have their shape adjustment parameters set differently.
And while I'm no "insider," it just makes legitimate sense to me that "well-done integration" may very well be part of the reason why a blend feature has not been added yet. There are many object-based features which are still very much works-in-progress, and I, for one am happy that everything existing is not yet "set in stone." My favorite example of something already existing that I very strongly hope will undergo dramatic change is Arrowheads. It seems to have been rushed out the door in response to very loud and impatient user demand. I hoped for —and still hold out hope for—something much more innovative and powerful.
JET

The Crescent tool appears to already have a "leaf" pre-set.
Then just use the corner tool as and when required