[Perspective grid]

+1 for a real perspective grid!

[[AD 1.8.3] After exporting Affinity thinks something has changed]

@walt.farrell @Wosven @carl123

Guys, I know what's happening here. That's why I posted this issue. Telling what I already know doesn't solve this issue. That's up to Serif.

To clear things up further:

1) I saved the afdesign-file right before exporting, so I'm sure nothing has changed.
2) I didn't change any export settings.
3) Export settings and export path aren't saved in the afdesign file, but globally instead at app space. To verify this just open file a.afdesign, export it to a jpg and save a.afdesign again. Open file b.afdesign and export it to a svg. Than open a.afdesign again and see it's not on jpg, but on svg. That proves the settings aren't saved into the afdesign file. Also the export path is clearly not saved into the file, but stored globally too.
4) I test things several times and don't post an issue if I'm not sure

 

[[AD 1.8.3] After exporting Affinity thinks something has changed]

After exporting to a file (to svg or jpg for example) of an already up-to-date-saved afdesign-file, Affinity thinks something has changed to the file (even though nothing has changed), and asks us to save the file when closing the tab. Even if we didn't change the export settings.

This makes this confirmation box unreliable and therefore error prone, as we can't tell by this message if something really has changed, or it's this issue again just saying something has changed, but is not.

[text boxes locked or frozen]

Looks like you posted this accidentally into the wrong forum. If you post this into one of the 'Report a bug'-forums chances are the developers see your post and can fix it.

[Animations]

10 minutes ago, SpectreDesign said:

I would love if there was an animation timeline in Affinity. 

This has been requested a lot of times already. Do a search on 'animation' and these are the results: https://forum.affinity.serif.com/index.php?/search/&q=animation

[[AD 1.8.3] Joining curves works counter intuitive and close path doesn't remove redundant node]

1 hour ago, anon2 said:

Two things:

1. Allowing the user to specify which start/end node of each curve is to be used when joining a pair of curves.

2. The Close Curve command should automatically remove the redundant node that is currently being allowed to remain when the open curve's start and end nodes are coincident

Yes, these are the most important ones as these would solve a lot of confusion, complexity and errors. 

Next to this my suggestion nr 2 in the initial post is: make 'join curve' usable for both connecting at front as well as connecting the nodes on the other side, so both joining AND closing. So we don't need to think about when to use 'join curve' and when to use 'close curve' anymore either when connecting two curves head AND bottom all the way around. A lot more user friendly if we could just select two lose ends and press 'join curve'. And do the exact same action with the other open end-nodes.

'Close curve' would still be needed, but mainly to use when trying to close open single curves that were single in the first place.

[[AD 1.8.3] Joining curves works counter intuitive and close path doesn't remove redundant node]

On 4/14/2020 at 1:30 PM, fde101 said:

If I correctly understand what you are trying to do

No, that's not what I'm trying to do. I refer back to my initial post.

[[AD 1.8.3] What is this path disappearing thing???]

3 hours ago, anon2 said:

For me, the state of the "align handles" snap has no influence on this "copy from another node" feature. 

 

9 hours ago, R C-R said:

The delay time begins when the first cursor badge appears & the copy & move isn't activated until the second one does, so (without other snapping options enabled) you would have to wait several seconds longer than you did in your video.

Yes, I understand when this feature starts working and I've seen it working several times now as you can see in the videos above. But in some cases it's obviously not working without turning off alignment of handles.

[Break up this forum?]

3 hours ago, BofG said:

Maybe a good compromise would be to force the user to select a tag denoting which app their post relates to?

Totally agree with this. Would be great. Although this forum looks like a generic forum. I've seen it elsewhere. Not sure if Serif or a third party can customize this to force tag inputs from users. Would be a great solution though. A filter to only show messages with 'Designer', 'Photo' or 'Publisher' tags (or combination) in those forums would also solve the 'lots of messages in the forum' and everybody can decide for themselves if they'd like to see all the messages of all three products or only a selection. So that would be great for us, as we can filter, AND great for Serif as they still can see all in one forum I'd say.

[[AD 1.8.3] What is this path disappearing thing???]

Alright! Now with the handles-alignment turned off my initial plan to make line drawings with shapes doés work as I was hoping! 😀

Pretty great feature this 'stamp curve' thing! 😚

@Old Bruce @R C-R @anon2

[[AD 1.8.3] What is this path disappearing thing???]

10 minutes ago, Old Bruce said:

I too just did some quick testing and I think the problem is that you have the Align Handles.... thing turned on. When I turned that off the snapping occurred after a slow 5 count.

Ah, Nice!! I forgot about those snapping and alignment functions up there. That did the trick indeed!  Thanks! 😀

 

[[AD 1.8.3] What is this path disappearing thing???]

51 minutes ago, R C-R said:

I think the only thing you might be doing wrong is not waiting long enough for the move & copy to occur. 

Look at the video: the icon next to the cursor clearly indicate I've waited long enough and it's in the 'stamp mode'. So I'd say either it doesn't work the way you think it should as by your example, or I am doing something wrong.

[[AD 1.8.3] What is this path disappearing thing???]

2 hours ago, R C-R said:

they can be converted to two nodes with handles such that the curvature of the segment between them exactly matches the curvature of the top edge of the shape below it,

That's actually a very nice use case indeed.

Did just some quick testing. Not sure if I'm doing something wrong, but can't get it to work here so far. The icon appears to indicate I want to 'stamp curve', but doesn't do a thing. But I didn't really invest time into it yet. Maybe I don't meet the right criteria or have a wrong order in nodes or something else is wrong.

 

[[AD 1.8.3] What is this path disappearing thing???]

If I would give it a name: I would call it 'stamp curve' 😀 

Have to let it sink in when this is really useful.

Just tried to create something useful with this feature, like trying to create this line drawing from objects:

...but it seems only the nodes on the target shape are left and the rest get truncated. And it only works on a single curve, not all curves in a 'curves' layer unfortunately. That would have been great!

Got close with little testing on open curves though, but there was some unexpected result (for me) when the curve left the 'stamp'-curve:

We can create silhouettes of character-curves though:

 

I'm sure there are other creative uses for this. Anybody else knows some real world use cases for this? Would be nice to share some! 😀

[The History Of Interactive Computer Graphics and Animations]

Making some extra illustrations for upcoming part four! 😃

[[AD 1.8.3] What is this path disappearing thing???]

@anon2  @R C-R Thanks guys for your answers. That looks interesting.

I did some tests here and see the curve nodes are getting the same positions as the target curve. And that is the target curve has 20 nodes, but the dragged node only 10, only those 10 nodes get the shape of the target curve. So in that case it's not the same as just duplicating the target curve.

But what's a use case for this? When would we like to use this over just duplicating a curve? Just curious

[[AD 1.8.3] Joining curves works counter intuitive and close path doesn't remove redundant node]

Just edited the initial post.

[[AD 1.8.3] Joining curves works counter intuitive and close path doesn't remove redundant node]

@anon2
Damn... looks like you're right.

This whole join curves thing seems to be implemented waaaaay too complicated and confusing in Designer and it's very difficult to wrap your head around it while designing. I'm starting to see why by these tests (and this is a very simple test even)...

I did some more testing and found the following, for me, totally unexpected and inconsistent IMHO (and very confusing while designing) results
(I will adjust the initial post later):

Demo 1A) It doesn't matter at all which nodes are selected and there don't even need to be any node selected to join. So we can't tell designer where to join curves by selecting nodes.
Demo 1B) The join always start from the end-node (the red node) of the selected curve which is the lowest in the layers panel!! So the layer order sets the master curve!!!
Demo 1C) It doesn't matter in which order we select layers (add layers to the selection). It really is about the order of the layers in the layers panel.

 

Demo 2) The join always starts from the end-node (the red node) of this lowest selected layer in the layers panel and connects to the start- or ending-node of the other selected curve which is the closest to that node in the viewport!! So picking the right node to connect to isn't dependent on start- nor end-point of the slave curve, but the closest node of those instead!!

Demo 3A) It looks like close node always joins the nodes on the reverse side of the nodes being joined with join nodes (even if we didn't use join nodes)
Demo 3B) When using close curve Designer keeps the redundant node instead of removing it (like join curves does)

[[AD 1.8.3] Joining curves works counter intuitive and close path doesn't remove redundant node]

16 minutes ago, haakoo said:

Just another approach;
If you want to lose all joining nodes,choose "add" instead of join>close
You can add nodes back yourself wherever you want.😃

@haakoo and @G13RL Looks like you accidentally posted this in the wrong forum/thread. This is a feature request.

If you like to add workarounds to the original question and specific situation could you please move it there to keep this one focussed on the feature request? Thanks!

BTW using boolean Add is not the solution to this problem. We already been there in the other thread. 

https://forum.affinity.serif.com/index.php?/topic/112853-joining-two-lineshow

[Joining Two Lines...How??]

Just for information and future reference; just made a feature request for this:

 

[[AD 1.8.3] Joining curves works counter intuitive and close path doesn't remove redundant node]

[Edited this post after more knowledge by doing tests]

This 'feature request' contains two parts:
1) The way join curves is build in Designer now is IMHO way too complicated and counter intuitive to wrap peoples head around while designing. I see others here, like me, struggle with this simple action. Tests show me why.
2) When closing a curve after joining two paths where the end nodes are exactly on the same spot (overlap), the redundant end node doesn't get removed (while that IS the case when joining paths).

About part 1:

This whole join curves thing seems to be implemented waaaaay too complicated and confusing in Designer and it's very difficult to wrap your head around it while designing. I'm starting to see why by the following tests (and this is a very simple example even)...

Demo 1A) It doesn't matter at all which nodes are selected and there don't even need to be any node selected to join. So we can't tell designer where to join curves by selecting nodes.
Demo 1B) The join always start from the end-node (the red node) of the selected curve which is the lowest in the layers panel!! So the layer order sets the master curve!!!
Demo 1C) It doesn't matter in which order we select layers (add layers to the selection). It really is about the order of the layers in the layers panel.

Demo 2) The join always starts from the end-node (the red node) of this lowest selected layer in the layers panel and connects to the start- or ending-node of the other selected curve which is the closest to that node in the viewport!! So picking the right node to connect to isn't dependent on start- nor end-point of the slave curve, but the closest node of those instead!!

Demo 3A) It looks like close node always joins the nodes on the reverse side of the nodes being joined with join nodes (even if we didn't use join nodes)
Demo 3B) When using close curve Designer keeps the redundant node instead of removing it (like join curves does)

 

My suggestion:

A lot of people here, including me, expect 'join curve' to be done on the selected end-nodes of both curves and close node to remove the redundant overlapping node. So no messing around with layer orders or whatever, or needing to remove nodes by hand, making things overly complicated. So my suggestions are:

1) Make join curves use the selected nodes to join.
That way we can decide ourselves in a logical and easy way which nodes will connect when joining curves. Of coarse we need to select outer nodes to join or otherwise it just doesn't do anything. So no messing around with layer order anymore and no need to think which node happens to be the closet (which limits us too); we want to decide ourselves which nodes to join!

2) Make join curves usable to close the curve too.
When joining two open curves on both sides, so it will be one closed curve, it would be nice if we could, instead of using 'close curve', use 'join curve' instead on the other ends, by selecting those two end-nodes. So join curves functions as close curve in that case, but with our control to decide which nodes we use for this and to keep things simple: than we only need 'join curve' to join curves. So we can 'join curves' on the start nodes and 'join curves' on the end nodes when joining two curves.

3) Make close curve remove the redundant node. 
When joining curves the overlapping nodes are truncated into one, so the redundant node will be removed automatically. Designer knows it's a redundant node because the coordinates are the same. The same should IMHO happen with close curve too, but isn't the case now; if we close a path and both end-nodes are on the same spot, than one of them needs to be automatically removed.

Hope you guys at Serif could find some time to re-think this join curves thing to make it easier, less error prone and more intuitive for us to use!

Thanks in advance!

 

[Joining Two Lines...How??]

6 minutes ago, haakoo said:

I joined the right two nodes and closed the left two nodes and pressed delete to delete the stray node on the joining part

Okay, well that delete node was some crucial information here... I couldn't see that delete in your video. Great you're telling me now 😉

Now it works! Thanks! 😊

BTW I think it's a little strange we need to delete that node ourselves when joining, but don't need to remove a node when closing the path. So for some reason close path seem to 'think' and remove the redundant node, while join path doesn't 'think' and keeps the redundant node, even though it knows the node is redundant as it's exactly on the same place as another node. 

Anyway, for future reference; so this is how it could/should be done:

[[AD 1.8.3] What is this path disappearing thing???]

When trying to solve/understand another issue with joining curves I just bump into another thing in Designer;

When I move the nodes of path A over nodes of path B and hold my pointer still, suddenly the moved path disappears. When moving again, it's back again, but when releasing the mouse on this invisible state it's gone forever.

It looks like this is some feature I don't know about, as the cursor changes when this happens and shows some kind of 'copy'-icon. But I never seen this before. Is this disappearing path thing really intentional? What is it for?

[Joining Two Lines...How??]

13 hours ago, haakoo said:

Steps:

HI @haakoo Thanks for your example. I converted the gif to mp4 so I could scrub through it and did exactly what you did. I even checked that the nodes were really on the same heights and they were. But still I'm having this issue. All node snap settings are turned on, like in your example and while snapping you can clearly see that BOTH NODES turn yellow to indicate they are exactly on top. So I wouldn't expect this to go wrong. But it does.

It still doesn't merge the nodes into one on the right side. Only on the left side, where the path will be closed, it works.

There must be something that's different than in your setup. I am using Designer 1.8.3.641 btw.

In the following video I did exactly the same steps as you did and in the same order too. Even the direction of the marquee selection I did the same to be absolutely sure:

[edit] BTW in the example I have 'Pixel alignment' turned on while you have not, but also when I turn pixel alignment off the results are the same. We could also compare our snapping settings, but that shouldn't make any difference as the nodes turn yellow and the values and interface clearly show that everything is matched up perfectly before joining and closing.

[Joining Two Lines...How??]

@firstdefence No offence firstdefense (no pun intended 😉 ) but I think we could all think of that solution, but I think you know we were in fact answering the real question here on the techniques of joining paths. You just can't solve everything with strokes and else we could also have answered to redraw the whole part with the pen tool and just close the path, right?

That said; if you like a challenge to answer a question; maybe you know the answer to my question I asked in my post above? As this one still isn't answered and I'm very curious to know, cause I'm starting to wonder now if this is even possible in Affinity: