Checkmate

I have now gone completely Adobe-free on my laptops, both home and work. I can't say I miss much at all, because I found their distort tools a bit confusing and unintuitive.
If I want to apply perspective or 'box based' distortion, what I do is open up Inkscape (free) and use their perspective tool. It's not ideal, I know, but it's pretty simple to paste my object into Inkscape, draw my container shape, then apply the perspective tool after selecting both. Then I simply copy and paste the result back into Affinity.
All I really need in Affinity (for the most part) is to be able to select the bounding box corners individually like in the Fireworks video above, then adjust paths or groups to fit a chosen shape. Yeah more complicated transforms would be great down the road, but this is what I would use regularly.

@Dazmondo77 There you go another pretty good example of what we're talking about and how it is used (although I'm pretty sure everyone knows what it is) : 
 

I just went to replace an image on an AD document and noticed this new option for Embed/Link.
I haven't seen this mentioned on any changelogs - have you accidentally pushed out the feature too early?
I also noticed images I tried to rename on my computer were throwing up an error because the file was 'already open in Affinity Designer', so it seems to be working.

+1 for this option too.
I've just been importing a couple of different PDFs into AD, one of which was created in Excel (I needed a table). The PDF import seems to choose Frame Text for some cells and Artistic Text in others (depending on what text options are selected during import).
Now what I want to do is scale the table vertically to fit a particular gap, whilst retaining the correct font aspect ratios. Frame Text is good for this but Artistic Text will end up all 'squished'!
If there was an option to 'Convert to Frame Text', it would save me looooads of time.
I always use Frame Text, but in my example above I have no choice but to start out with Artistic Text.

Not sure I'm a massive fan of the Inkscape snapping icons.  I get the point though.
 
There is one difference in the way I'm tackling snapping.  We have a separation of general and tool-centric snapping.  Some snapping 'features' are only really applicable within a tool.  For example, snapping of curve node and handles only really applies to the Pen and Node tools.  So, I'm not putting options for those in the general snapping setup panel.  If every tool that has some form of local snapping had their options in the general panel, it'd get very full.
So, for 1.7, there were some snapping options that have now become tool centric.

I've been getting annoyed with this too. I never use the 'slice' tool, I always use the 'select' tool when exporting.
 
Couldn't the export persona just default to the first tool in the list, then people like me and VectorCat could move the arrow to the top of the toolbar?

Every time I return to the Export persona, I think the arrow tool is still active, swipe my item, and lo, a new slice is created which I must then delete. And that is because upon entering the Export persona, the slice tool is the active tool.
 
maybe the behavior could be last tool selected is the tool that's active when you enter Export again?
 
Thank you!
 
vcat

Like I said, you'd snap your direction first, then perform a second mouse drag while holding Shift to fix the handle length - then you'd have a perfectly symmetrical curve segment.
 
Demonstrated: SnapToReflectedPlusLength.mov
 
It has to be done as two separate actions, else you'd have two independent types of snap that would fight against each other. While it is another step, it means you'll have greater control over the curve.  Since we use Alt to cancel snapping outright, you might otherwise end up fighting against snapped lengths while all you really wanted was to fix the direction.

Ok, Here are some videos to demonstrate all the snapping that I've added for handles.  Please note, I'm not talking about snapping to grid, I am talking about snapping to useful construction angles relative to the opposite curve point and handle.
 
So, the following snaps are shown:
 
1) Snapping to smooth a cusped node - SnapToSmooth.mov
2) Snapping to inline, and 90 degrees to inline - SnapToInlineAndNormal.mov
3) Snapping to reflected angle - SnapToReflected.mov
4) Snapping to parallel direction - SnapToParallel.mov
5) Snapping to 90 degrees of parallel - SnapToParallelNormal.mov
6) Snap to logical triangle (useful for square corners?) - SnapToTriangle.mov
 
The useful thing about these snaps is that they will enable you to perform common curve construction, completely independent of grid or set axis.  You can use them in tandem with a second action while holding Shift to snap the handle lengths to match the preceding or following handle (while maintaining the direction you already snapped).

I assume that in your mind, your mean Professional = Corporate? I'm a developer, and I'm on the forum trying to help out. I have the best knowledge of our software, our code, and I can actually fix or implement features. Yet for some reason you would rather speak to a marketing person? Or a member of a support team? Or someone else that can't actually implement the change that you want. That's certainly not the feedback we've received from the majority of our other customers - they really appreciate being able to speak directly to development staff.

At least so far as CS6 ('cause I won't rent business-critical software), Illustrator still can't actually crop a raster image; it can only mask it.
For the benefit of those who may not have "been there," Illustrator trailed versions (i.e., years) behind its historic nemesis, FreeHand, in all these areas:
Editing in Preview Mode. (In other words, simply being able to edit paths with their stroke and fill attributes showing.)
Compound Paths. (Making a path with a hole in it.)
Clipping Paths. (Ex: filling outlined text with a raster image.)
Performing alignment and distribution on Anchor Points (nodes). (Still sub-par compared to FreeHand because Illustrator's insistence on two separate primary selection tools effectively prevents it from "knowing the difference" between a path being selected at the object level, as opposed to merely having all its nodes selected.)
Page 2. Egads! What a concept! The garment-rending, sackcloth-and-ashes outrage from Illustrator devotees (who had practically zero experience with FreeHand or any other drawing program) anytime the need for multiple pages was even mentioned, was just laughable. Why, it was going to be the end of the world; the coming of the apocalypse; illustrators everywhere would be committing hara-kiri!
Predictably, many of those same users now no doubt couldn't live without it. Many probably think Adobe invented the idea. And Illustrator's treatment of it is still cumbersome compared to FreeHand's more straightforward interface.
Basic Math Operators in Value Fields. Another one still inferior to FreeHand's. Illustrator can still only manage a single type of operator in an expression (i.e., multiplication/division or addition/subtraction, but not both).
User-Defined Arrowheads. And man, what a hack job of an interface!
Converging Perspective Grids. Adobe had to acquire FreeHand to copy this one.
That's just off the top of my memory. I could go on.
I've said it here before, and I'll say it as long as it takes: Simple market share no more correlates to functional superiority in drawing software than it does in, say,  motorcycles (my other passion). Illustrator is not the program to emulate. I've seen evidence sufficient to convince me the spunky Affinity Team probably gets that. Some feature requesters...I'm not so sure.
And yeah, time is of the essence in the current window of opportunity opened by Adobe's Customer-alienating licensing change. But compared to the pace of Illustrator's development over decades, development progress of the Affinity line is lightspeed.
JET
 
 
 

Steady on.  Not a great way to motivate us.
 
Priorities doesn't necessary just mean what we think is important, but also what things have to be done in a certain order, and whether those things collectively also are more important than other features which need attention. It is also a balance of how much work is actually involved in what might appear to be a small feature.
 
I have just spent months refactoring a lot of our internal tools in order to facilitate faster future development and enabling editing features across tools.  This was a big task, but the few changes and additions I have made off the back of this have already demonstrated that this was time well spent.  Now, as a user you will have no idea of the scale of the work involved in changing our internal framework while preserving the current functionality of our tools.
 
Software development is a fluid beast.  Only as our code base expanded did it become clear that things could be achieved in a different/better way.  Due to a lot of commitments already made, the changes I wanted to make got pushed back a number of times. I have now made them, and 1.7 will come with some significant additions - though the scale of work to implement them might still not be obvious to the end user.
 
This thread is to show a raft of new (hopefully innovative) features that are in the pipeline, and you are accusing us of pretty much doing nothing to improve the software...!? All of these additions will achieve 99% of the use cases that have been thrown up (while not tying you to a very limiting grid based drawing method) - the only exception being the ONE use case where you want to be able to easily replicate sets of curves built previously using known grid positions for handles. (If I am missing the other use cases, you will have to explain them individually). AND, I have already made many comments as to why this feature will conflict with our current tool usage, but I think I have even said that we will try and add it.  So what is the problem?  You are not going to be getting 1.7 Beta just yet anyway, so why is this turning into a rant?  We have heard your request, and while I would personally argue that placing curve handles on grid produces a very limited artistic scope, I will accept it is the way you like to work.

Yes, but merely constraining angles to a desired set of axonometric axes can be accomplished in any program that provides a user-defined constraint angles feature (ex: the Constrain Guides sub-feature of Illustrator Smart Guides, and similar features in CorelDraw and ACD Canvas) without need for a page-spanning grid.
What's always missing in those features, though, is any provision for assigning correctly-proportional ruler scales along the constrain angles. That's why I said in my previous post "If grids are to serve as the rulers...":

I'm glad you're looking into that, because there has to be some provision for specifying properly foreshortened and accurate measures parallel to the three axis directions from any snapable point in the drawing.
One possible treatment might be a radio button set in the Transform palette labeled "Axis Scale" versus "Page Scale." That would at least provide a substitute for what other mainstream drawing programs are missing in their user-defined constrain angles. Moreover, it would enable entering measures in terms of true-measure values.
But even that does not emulate the direct intuitiveness or elegance of even a pre-computer drafting machine. Axonometric drawing, by definition, is all about making correctly-proportioned direct measures along three coordinate system axes (i.e.; each axis must have its own scale factor, and those scale factors must be correctly proportioned to each other), and zeroing those measures from elements of the drawing, not from increments of a grid. And performing such measurements should not require looking away from the drawing to a palette.
That's why I said that if grids are the only provision to serve as those on-page rulers, then the intersection of the grids needs to be able to be instantly and fluidly zeroed to any point wherever a mousedown occurs, just as the scale head of a physical track drafter effectively "moves" to the point of interest in the drawing and allows the illustrator to perform a measure from there without having to look away from the drawing.
The closest emulation I've yet seen of the kind of fluidity I envision is Lazy Nezumi Pro (so close, yet so far). In its isometric rulers preset, three rulers appear at and follow the cursor. Unfortunately, when set to other axonometric angles, those three rulers do not currently display proportional scales; all three still show the same scale. (I anticipate this changing, since LNP's converging perspective rulers do display proportional scales.) Plus, being an application-independent "overlay" seems to limit its functionality for vector drawing because (among other things) it is unaware of the program's zoom. And though tick marks were just recently added to the elliptical rulers (thereby allowing them to serve as elliptical protractors--something essential to serious axonometric drawing), the increments are not yet snapable.
But the interface concept is quite sound and elegant (and not unlike similar cursor-following interfaces of high-end 3D modeling applications). A similar treatment actually built into a 2D drawing program would not have those limitations.
For example, imaging drawing with the Pen Tool in its Straight Line mode:
The Axes feature is turned on. Three light-colored axonometric ruler guides appear, with their origin under the cursor. There are correctly-proportional tick marks along each of the three rulers. This set of guides always follows the cursor during mouseup, while the cursor responds to all the normal snapping candidates.
Upon mousedown, the rulers stay put.  The user drags along one of the axis guides. If he holds a modifier key, the cursor snaps to the tick marks of that axis. If he releases the modifier key, the angle constraint is still active, but the tick mark snapping is not. Either way, though, a distance readout (accurate to 4 decimals, please) continually appears next to the cursor.
That allows the illustrator to draw quickly with reasonable precision without having to look away from his drawing and toward a transform palette. But the transform palette (assuming its Axis Scale checkbox is on) can still be used to manually enter exact length.
Given such an interface, a page-spanning grid would not even be necessary. Sure, it would be useful when one wants to automatically "project" side views drawn "in the flat" onto the axonometric planes, and that's fine. But most of my drawing would be done with the grid display turned off. The whole purpose of axonometric methods is to allow the illustrator to intuitively draw directly into a mechanically-correct 3D orthographic perspective without having to draft side views first.
Oh, I'm all for some fresh innovation rather than just conventional wisdom. I look forward to seeing what you have in mind for the new feature. I just hope it's not too "locked in" to be open to some user feedback in terms of the implementation.
JET
 

How about an extra section in the drop-down for 'Mixed'? When working with UI design and anything with a web element, the starting point is often a hex code.
 
I've lost count of the number of times I've started with a client's hex code from their website, then introduced a 'darker' and 'lighter' version of the same colour (for a new logo design etc.) The easiest way to do this is by sliding the L up and down on the HSL colour mixer.
 
In this sort of web-centric workflow, a 'combined' colour picker makes a lot of sense.

Regarding the axonometric grids and ruler origin reset:
Hopefully before these two related sneak peek features reach a customer beta stage (in which feature schema and behavior is mostly already committed and focus is mostly just on bug testing), I want to throw this out, so I can sleep at night:
Having been doing isometric drawing since the days of drawing "on the board" before desktop computers, I dare say you won't find anyone more enthusiastic about adding some geometric intelligence (other than just snapping) to the plane grids (more akin to DrawPlus). Such grids are a great way to introduce commercial illustrators without prior experience to axonometric drawing.
So don't think it contradictory when I say this: In all those decades, frankly, I have never met a fellow serious axonometric illustrator who is highly dependent upon grids; neither before the advent of graphics software nor since. Here's why:
There is a fundamental concept which the trivial "isometric grid" features in mainstream drawing software typically gets completely "backward":
As usually implemented, grids make your drawing conform to the grids, when the grids should be adapting to the drawing.
Grids tend to force your drawing to conform to the increments of the fixed grid. That's fine for "fantasy" drawing like, for example, bird's eye view game artwork wherein the actual dimensions and spacing of whatever "boxy" shaped things you are drawing are entirely up to you. But in real-world technical drawing, it's not about just drawing conveniently "boxy" things, and it's not about making your drawing measures conform to a fixed grid; it's about having a set of freely moveable and correctly proportioned angled rulers which enable you to make correctly-scaled measures from any point in your drawing.
In pre-computer days, the only time you saw a tech illustrator using a grid was when he was away from his drawing board (or when his drawing board was not equipped with a track drafter). Newbie illustrators would sometimes use a printed axonometric grid under a sheet of tracing paper. And guess what: He would be constantly moving the grid around under his drawing sheet.
A technical illustrator is not the least bit concerned with measures incremented from any page origin. He's constantly gliding his properly-angled rulers to make measures from pre-existing points in his drawing.
If grids are to serve as the rulers for axonometric drawing, they need to be able to act like rulers and freely follow the cursor, not be stuck to any page origin. The origin of the grids (the intersection point of the three planes) needs to be able to snap to any snapping candidates in the artwork, completely free from interference from a page layout grid.
This is essentially why no grid-based approach has ever really matched the quick, easy, intuitive fluidity of a physical drawing table equipped with a mechanical track drafter. The closest software emulations of the fluidity of the physical tools metaphor are not grids, but three proportional rulers (axes) which follow the cursor, as in some 3D modelers.
But axonometric drawing is, by definition, a 2D construction method historically performed on a 2D sheet of paper. So there's no reason a similar interface could not be provided in a general-purpose 2D illustration software, based on 2D geometry.
JET

And, here a video showing the new rotate-on-plane feature of the Move tool.  A new shape is created into a grid, using the "Edit In Grid Plane" mode.  Then, with the mode on, any rotations maintain the grid plane perspective.
 
RotateOnPlane.mov
 

How about an extra section in the drop-down for 'Mixed'? When working with UI design and anything with a web element, the starting point is often a hex code.
 
I've lost count of the number of times I've started with a client's hex code from their website, then introduced a 'darker' and 'lighter' version of the same colour (for a new logo design etc.) The easiest way to do this is by sliding the L up and down on the HSL colour mixer.
 
In this sort of web-centric workflow, a 'combined' colour picker makes a lot of sense.

Agreed, I hate the process of a cumbersome drop-down menu, just to paste a hex code in.
 
On a similar note, it would be useful to support 3-digit hex codes too (ie. #333 being the shortened version of #333333) as these are regularly used on modern websites. Currently pasting #333 will result in Affinity converting it to #000333, which is obviously a totally different colour.

I've done these to match the other icons I've on my Yosemite's dock  :P

I copy and paste hex numbers quite often.
The nice thing about the PS color picker is having HSB, LAB, RGB, CMYK and hex box are all in one window.

Is there an option to remove the raster texture part of these brushes to leave just the vector outlines?
I tried exporting an EPS of a logo I designed using Daub Inker 'Quick&Dirt' and the file size was pretty huge at 300dpi.
In the end, my workaround was to export a hi-res PNG then trace this in Inkscape to create a rough outline of the brush strokes, then copy and paste them back into Affinity. I separated the different colours of brush to maintain my layers and make tracing easier.
Ideally I'd like a tick box in the Brushes menu that says 'remove raster textures' or similar.

+1 for this. 
Just in case you don't know, you can create 1 handle by dragging a node with pen tool + ALT.

I wasn't sure where to post this idea, but here goes...

I just saw this today. An open source app (midi2lr) that lets you control LR via a midi controller. The obvious benefits are that you can have a hardware or virtual (think IPad based) device with dedicated analog controls (sliders, buttons, toggles, etc.) custom tailored to interact with AP.
 
Take a look here to see what I mean.
http://petapixel.com/2015/08/12/midi2lr-an-open-source-app-that-lets-you-use-any-midi-controller-in-lightroom/ (video at bottom, 1'41")
What a great interface for interacting with a photo editor!
 
There seems to be 3 components needed:
1. AP API (possibly via the Extension specification?)
2. MIDI2LR (fork open source project to create MIDI2AP)
3. Midi controller. These range in price from $ - $$$.
 
Is their a high-level API for AP to allow for this type of input? Maybe via an Extension? Not sure as I haven't been able to find any documentation around this specification.
 
Here is another example showing LR being controlled with an inexpensive midi controller.
https://www.youtube.com/watch?v=dRwkDZguAQg  (16'03")
Thanks for your time.

Thoughts?
 

I know that layer effects come out of the land of Photoshop compatibility, but I'd like to propose a new one which would create unlimited-size "long shadows'--solid, not offset dropshadows extending in whatever direction from a type or shape layer. There are workarounds for this, but most involve rasterizing the type (so if you change the kerning, you have to go back through again.)
 
How about it?

I was totally going to post this exact same thing! Agree 100%