Jump to content
Our response time is longer than usual currently. We're working to answer users as quickly as possible and thank you for your continued patience.


  • Posts

  • Joined

  • Last visited

Everything posted by robinp

  1. 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.
  2. 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.
  3. 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/
  4. I came here to check before buying v2. I honestly cannot believe they haven’t fixed this. Astonishing.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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
  10. 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.
  11. 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.
  12. 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.
  13. @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.
  14. 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.
  15. I made a similar suggestion somewhere previously. I thought of it more as a ‘tag’ system. But essentially the same as you’re suggesting for the second part. I’m assuming the first part of your suggestion is dealt with by the file format structure. Or at least it should be.
  16. The message was from about half an hour ago saying it is one of the next things on the list.
  17. I can’t quite believe it. It is also kind of funny that it comes in a different thread to the one that’s been going for years and years
  18. Yeah, there’s a lot of excuse making that goes on in this and other threads for why really simple features haven’t been implemented. Quite often they veer towards the “we should want something better than the basic solution offered elsewhere”. Except what everyone is crying out for IS the basic solution available elsewhere as a minimum. There are, of course, obviously many ways the ‘select same’ tools in Illustrator could be improved upon. It sounds like Freehand had a much better solution for example. And probably there are much better ways that are available now than there were ~20 years ago with computing power being dramatically increased and resolution of computer screens allowing much more UI detail / info than before. But, it doesn’t get away from the fact that a basic feature could and should be able to be implemented very quickly. That would be sufficient for people to get their work done. If an earth shattering revolutionary solution is coming years down the line then great, but please just deliver the basic one quickly first so that we can get on.
  19. To be fair, I think if the Serif team opened up to the community and said something like: "we messed up, we should have dealt with this request years ago but we are now focussed on delivering it ASAP. However, we would love your ideas as to how best to implement it to make it the best implementation of such a feature in any app" That would have changed the course of this discussion and many would be enthusiastically coming up with and discussing ideas. That's not happened though and don't think it is really the fault of the community.
  20. If that’s the case, then why didn’t you just react to my message and leave it at that?
  • Create New...

Important Information

Please note there is currently a delay in replying to some post. See pinned thread in the Questions forum. These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.