robinp

Open / save dialogues are provided by macOS unless a developer decides to make additional work by completely implementing their own. I’m an iOS developer so I’ve not used them, but given every other app has the same behaviour when it comes to save location, its extremely likely that Serif did extra work to implement the non-standard macOS behaviour. Now we are several years down the line, they would have angry people either way if they suddenly changed it to the correct behaviour. So the only viable solution is to provide a toggle in the settings. Heres a scenario where things can go really badly wrong: You are working on multiple projects and have a shared folder with an external party (client, partner, whoever). As a well organised business, your projects have a standardised folder structure. Therefore every project kind of looks the same once inside the top level. Later in the same day, you re working on some sensitive, private information for another client. It’s the same day and you create a folder with the same issued date of today (because you’re organised and keep records). You save the file. Only it defaults to the save location of the other project, a folder that looks essentially identical at a glance. The big problem is that you’ve shared the folder with the other project already. So immediately there’s a data incident. This is entirely caused by Serif’s insistent that Affinity apps behave in non-standard ways. When people do common tasks like save a file, there are behaviours that are normal on a platform. These shouldn’t ever be messed around with. At least not without express consent from the user.

Yeah, it is like it is set up to intentionally trick you. I would say though that per your first part of your reply, there is a ‘right’ and a ‘wrong’ here. When there’s a platform norm, that is the ‘right’ way because it is what everyone is used to and expecting. Anything else is a trap and leads to dangerous (yes, data security is a serious business) situations. If people want non-standard behaviour, then fine, let them have that as a user selectable option. Don’t inflict this absurd situation on everyone else.

I really like Affinity apps. But whenever I use them I feel like I’m constantly being tricked / trapped by them. I work on a file then save or export and the location inexplicably defaults to the last location of save or export, not the location of the currently open file. It’s a topic that’s been discussed at length here over the years. But I simply hate the current behaviour. It causes stress. It causes data issues. It causes embarrassment. It causes extra work. It’s entirely unnecessary. It’s terrible customer service All because someone at Affinity has a somewhat bizarre idea about how save dialogues should work that’s different from every other app. It’s just not good enough. Sort it out. I’m done with waiting patiently.

Personally, I strongly think that the default behaviour for save as should be to save in the same location as the current file. If you’re working on a project, the vast majority of times you want to do a save as operation it would be in the same folder or a folder that’s close to in the folder tree hierarchy. That you might have been messing around with some random other file earlier in the day and that location would be the default save location makes no sense at all. However, I agree that having some kind of ability to override the default is reasonable. Just perhaps the overrides should be a bit less specific.

Of course I have no problem with a choice being offered. Especially given this atypical behaviour has been happening now since the start of the Affinity apps, presumably it would be irksome to some people. But to ignore platform norms is unacceptable.

I understand this is not fixed in v2. Very disappointing. I had been assuming faults like this weren’t being fixed in v1 because they would be in v2. The problem is that ‘save as’ dialog should start with the directory of the current open file. Not the location of the last saved file. Many reasons are given in the previous discussion which is now archived (link below). The main overarching one is that this is the way that all other apps work. So it is like a trap. It is contrary to the way everyone expects things to work. If you work on multiple projects and you have a well structured project folder system, the chances are that one folder for one project looks much like the folder for any other project. To spot you’re saving a file in the wrong place is virtually impossible. The usability is horrendous. https://forum.affinity.serif.com/index.php?/topic/17825-default-location-for-save-as-and-export/page/1/

I came here to check before buying v2. I honestly cannot believe they haven’t fixed this. Astonishing.

I would also like this to be settable as a default option for paste. I rarely want to paste with formatting. For now, I've altered the keyboard shortcut so that Command+V has a binding to Paste Without Format instead of Paste. I guess that's an OK solution for me, but I imagine lots of others will never do that.

It might well be controlled by the plist, but to say that this is normal macOS behaviour would be simply wrong. The save behaviour of Affinity apps is perhaps unique among the macOS apps I use. This is part of the problem: it is utterly alien. The other part of the problem is that it is rubbish regardless of whether it is alien or not. If you accept that this is a problem, then we are never going to get apple to fix it because this is a choice that has been made by Serif for their apps in how they interface with macOS. There is nothing apple could do to fix it because it isn't a problem of their making. How do I know that? Because every other app I use works the *correct* way. The only people that can fix this is Serif. So please stop complaining about repeating your potentially technically correct point that simultaneously completely misses the point of this conversation. Edit: does anyone know where the .plist files for Affinity apps are located? I've had a gander around the various Preferences folders where these are typically located and I cannot see anything. Edit 2: found the plist files. ~/Library/Containers/com.seriflabs.[appName]/Data/Library/Preferences And there is nothing I can see in there that controls the default save location. I suspect if it were as simple as a plist setting, Serif would have provided a toggle in the preferences panel for users to be able to select which behaviour they wanted a long time ago. It is very likely hard coded into the apps.

Hi, any update on when this will be fixed. It is painfully slow.

Whilst it’s great that this feature is now included, there’s no evidence that this 26 page thread had any impact on the inclusion of the feature. Given the 7 years or whatever it is since the start of the thread (can’t remember and haven’t checked) it would be hard to believe that this feature wasn’t just always destined to be included in v1.9.

I understand your sentiment of being realistic and providing advice, but part of the point of these forums is to communicate with Serif about problems and feature requests. The behaviour as it is currently is terrible. So it’s reasonable to hope that it might be fixed one day. Yes, I realise others might be OK with it as it is, but even after several years I still find it incredibly bad.

I'm having the same problem. 16" MacBook Pro with Big Sur.

It's really beyond annoying that 'All pages' is not the default and not only that, but you cannot save it as a preset so you cannot even change the default yourself. It is basically a faulty implementation. Surely this change would be trivial beyond belief. @MEB

To be honest, I'm actually pretty happy with using macOS Photos.app as my photo library. I like that it works with iCloud photos so I've got all my photos wherever I am and whatever device I'm using. Perhaps what I'd request is a library interface in Affinity Photo on Mac that exposes the photos / iCloud library within the app. I guess different libraries and types of libraries could be accommodated so you could potentially also add a google photo library or create a new local one from scratch.

Thanks, and sorry for the really slow reply. The Replace Image button in the toolbar is much easier. The sorting by page # helps but doesn't really solve the issue. Still think that being able to set the resource manager to not collapse the list and to highlight the resource selected in the document (not quite the same as using the 'locate' tool) would be helpful. Mainly, not showing collapsed lists in the first place so that you don't have to do multiple clicks of selecting and deselecting and reselecting again. For now, I'll just try to get used to working with the toolbar button.

It would seem advantageous to have “soft select” settings so that you could define only exactly the same colour or same + similar colours. That second option would pick up RGB + CMYK colours that are similar whereas the first would only select the precise RGB or CMYK colour.

Finally. So pleased this has come and it is part of the 1.X version series. Looking forward to trying it out

@Gabe @MEB any chance one of you could communicate how essential this is to someone that can do something about it? Being able to find the scaled size vs the original size of a placed file (I honestly don't give a monkey's if it is a JPG or a PDF, both should behave the same) is really incredibly important. It cannot just be those of us working in the built environment that find this omission a total pain in the bum. There must be loads of designers and people preparing instruction manuals etc who need to know what size an image will be output at.

Well that’s: a) pathetic and b) really unhelpful Our workflow requires it. So you’d better make sure this is something that does work. Working on files across a network is not a new thing. Does Serif consider the suite to be suitable for professional use? If the answer is yes, then working on files across a network is about the first feature on the list. Sorry for the tone, I am just completely stunned that this might actually be a legitimate and genuine approach. Someone needs to get a grip, because it is laughable. Anyway, it’s been fine working across a network since even the earliest public betas. Since linked files have worked properly it improved greatly. I can’t really share a work flow. Unless you want me to show you a video of me clicking save from the file menu. As for file samples, as you can imagine, I rescued from a back up and got rid of the corrupted ones. Next time it happens, I’ll be sure to keep them.

I've never had a problem until recently. The file is not massive although if all the linked files were embedded then it would be huge. File is 68MB. But I'm getting 100% CPU use for extended periods when duplicating or deleting pages. This is crazy. Saving takes about a minute. My network is not that slow.

I cannot be the only one who needs this but I've been after it now for a couple of years. Most of our documents include scale architectural drawings. Often, we might have consecutive pages with different drawings of the same project. For example, floor plans for a multi-storey building. When inserting these, we want to: Know the scale at which these files are inserted Be certain of the positioning such that when move from one page to the next the drawings align with each other. For example, page 1 has the ground floor and the next page might have the 1st floor. These should be positioned exactly on top of each other so that it doesn't jump around when viewing on screen Currently, doing these two very basic and essential things are a complete pain in the bottom. Summary of the problems: If you crop an image (either as a frame or an inserted image), when replacing the linked file the positioning changes. I would say this is probably a bug. When replacing a placed image its positioning should not change between the page and the inserted image / PDF. it should be possible to identify how an image has been scaled relative to the paper size of the image. For example, insert an A1 PDF drawing that is at 1:100 scale and reduce it in size by 50%. That would then be at the scale of 1:200. All very well when inserting it. If you come back later or if someone else works on the document it is impossible to find out how it has been transformed. The only option is to reinsert it. That is stupid. Related to the above, preflight reports when images are not scaled proportionally. Can I find a control / information within the interface to control this? Of course not. This is puzzling. These two (three?!) things are making it REALLY difficult working with scaled drawings. If anyone has a good workflow / workaround for these failures please let me know because I'm pulling my hair out and simply don't get how these a) were left out in the first place and b) have still not been sorted out. Hopefully it's just that I am looking in the wrong place and this functionality is there somewhere.

It seems that things are really not very happy. So many crashes. VERY slow to save. Huge pauses when duplicating a spread. Images are linked rather than embedded so the file size is not crazy big. It's driving me a bit crazy. Anyone have any tips of things I could try to get it working well? @MEB

I'm having a lot of crashes when saving files to a network drive. It results in corrupted files. Needless to say, this is a really big problem.

Hi Chris I’ll have a look. Having experienced this problem a few times a quit and reopen or restarting of the machine typically fixes it. So I don’t think it is file related. This happens periodically and I’ve mentioned it before over the years but this is the first time I thought to record it before restarting etc. Over the last week or so I’ve been working with about 50 images. Open RAW files, develop (or merge to HDR) and then make adjustments. It seems to occur after working on many files in a row. It never seems to be the first few files where this weird behaviour shows up. Re photo persona, I really don’t like the persona thing and ignore it. I have no idea I’m afraid. I open RAW files and work with them. What goes on on the top left isn’t something I pay attention to.