"Save As ..." Where the file came from, please!

[johndmoulton]

"Save As ..." Where the file came from, please!

Here's the issue:
I'm working on file A from Folder A. While doing so I open file B from Folder B in another tab. I am now working on two files in unison - sometimes important for continuity of colour etc.
But when I come to save Illustration A with 'Save As ...' the system automatically opens the last fold I took a file from - in this example It automatically offers Fold B for File A.
I know the answer is use the folder drop-down, but sometimes I don't notice, particularly if folded A&B have similar names. Then later, when I want to retrieve File A, I often wonder where it's got to or cringe at the thought that I failed to save it!
Can't a file have a background (unseen) tag indicating where it came from so that the system knows where best to suggest saving it?
BTW: I know Cmd/S already does this, but does that not work if I want to keep the original File A and Save As File A2.
Hope that makes sense.
John.

[Pšenda]

1 hour ago, johndmoulton said:

Can't a file have a background (unseen) tag indicating where it came from so that the system knows where best to suggest saving it?

No "invisible" tag is needed - the application knows the full path of the file it opened (otherwise it would not be able to save it with Save).

[johndmoulton]

Pšenda: I thought so too, hence the question: Why is a file's original path 'overwritten' by the path of the latest file opened and suggests that in 'Save As...'? Seems the system's 'memory' is only capable of storing the latest file path in that circumstance. So yes, 'Save' and Ctr-S suggest the folder the file came from, but 'Save As...' does not, once you have opened a second file with a difference source folder.

I may want to create several versions of the same image in the same folder, but if I have opened another file from another folder since opening (in this case)' File A' the system goes to the latest folder accessed. So, when I want to save the new version as (say) File A2, the system goes to the latest folder accessed, NOT the folder the original 'File A' was sourced from.

[bvf]

Yes, I also would like the ability to save an edited file back to its original folder, either as a "Save As ..." option or a setting to always save back to original folder.

[Bound by Beans]

Serif has chosen – and stuck with – the decision that your workflow should be disrupted or broken in this way, despite repeated feedback from customers. How does it feel?

Thank goodness I work on long-term projects with SAVE on the same file for months — otherwise, I probably wouldn’t be able to put up with Affinity’s behavior.

[bvf]

It should be up to the user how to organise their workflow, not the software developer. If there are lots of customers asking for this change, how difficult could it be to provide the facility - why not just provide it?

[Pšenda]

2 hours ago, bvf said:

If there are lots of customers asking for this change

Given that there are approximately 3,000,000 customers and users of Affinity applications, it is clear that most of them do not require this change.

[fde101]

Depending on the reason for saving multiple versions of the file, one alternative that might help with this is to save snapshots within the file instead (Document -> Add Snapshot) and just use the regular Save command.

This doesn't cover all use cases though, so it may or may not be appropriate for your particular situation.

 

 

I should also point out that not every workflow has the same requirements on this: I have a situation (with a different program) where I regularly open all files from one folder and export them to a different folder.  Everything opens from folder A and everything exports to folder B, but A is not B.

[Granddaddy]

22 hours ago, Pšenda said:

Given that there are approximately 3,000,000 customers and users of Affinity applications, it is clear that most of them do not require this change.

The logical implication of this argument is that most customers do not require fixes to any of the myriad bugs in Affinity products, nor do they require any improved or additional features at all. After all, they bought Affinity apps in the past so they must be satisfied with the apps as they are. Can there really be 3,000,000 active users of Affinity given that so few seem to participate in these forums?

I am reminded of F. M. Cornford's opening sentences in Chapter VII of Microcosmographia Academica:

"There is only one argument for doing something; the rest are arguments for doing nothing.
The argument for doing something is that it is the right thing to do. But then, of course, comes the difficulty making sure that it is right."
https://www.cs.kent.ac.uk/people/staff/iau/cornford/cornford7.html

For the sake of argument, let us assume that 3,000,000 individual people have purchased one or more Affinity apps. Let us also assume that a person like myself who purchased two Affinity 1 apps and three Affinity 2 apps is counted as only one customer and not as five customers (i.e., not counting one additional customer for each app purchased). Does this really imply that I do not require any changes in the apps?

Of course, it does not. I require several changes in the apps. This is why seven years after my first Affinity app purchase I now mostly use an alternative product for almost all of my photo editing. I've hardly used Affinity Photo for the past several months because it lacks features I require for my routine photo editing. 

The more important question for Canva is not how many people purchased Affinity apps in the past but how many of those who purchased Affinity apps in the past will purchase more Affinity apps in the future?

I have written elsewhere in these forums that Affinity must provide a compelling reason for purchasing additional Affinity apps. In recent years Affinity has instead provided compelling reasons for me to look elsewhere for my photo editing requirements. This is a great disappointment given the time and money I have invested in Affinity apps.

[Pšenda]

9 hours ago, Granddaddy said:

The logical implication of this argument is that most customers do not require fixes to any of the myriad bugs in Affinity products

I hope you don't take this seriously, because that's completely wrong logic - a bug is simply a bug (if it's really a bug, i.e. a deviation from the declared behavior of the application), which only needs to be reported once (there's no need to report it repeatedly).

You've probably noticed that this was a counterargument to the claim, which was based on the assumption that if "lots of customers" request a modification, then Serif should/had to have done it a long time ago! Although it's obvious that Serif's development capacities are considerably limited, and that a certain prioritization of work is therefore needed when fixing bugs and implementing new features, the argument here is made in the style of "lots of customers" but without taking into account all other customers.