Jump to content
You must now use your email address to sign in [click for more info] ×

robinp

Members
  • Posts

    467
  • Joined

  • Last visited

Posts posted by robinp

  1. 12 hours ago, Bit Arts said:

    Yes, of course you have to comply with platform standards, but they are often quite banal and generic for Mr. and Mrs. Steak. When you finally become a field marshal and get a conscript's uniform, happiness is not just around the corner for the expert. 🙂 

    It's important to come up with alternatives, as workflow is king among professionals, people with similar needs and especially those who work with massive amounts of work every day, who have to go through these repeated unnecessary interruptions. Fortunately, in my truly professional programs, I see that they provide deviations or alternatives where the standards don't work with customers' professional practices. Save location is a classic example of something that's really annoying out there, and not just that it interrupts and annoys, it takes extra time, and time is money. 

    My guess is that Serif's main motivation for implementing it this way is to make it easy for themselves with simpler functionality and easier to maintain cross-platform code. It's a sound philosophy to start with, but as I said, everything has to be weighted against customer needs.

    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. 

  2. 7 hours ago, Bit Arts said:

    7 billion people can argue about whether A or B is relevant for as long as they can argue about whether coriander tastes good or bad. No one is right; everyone has a preference. But when it comes to this particular behaviour, it should be optional. For me personally, it is incredibly time-consuming as it is implemented now;

    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. 

  3. 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. 

  4. 22 hours ago, Ian92.art said:

    I have to say, my anxiety spikes every time I look at this forum, and I've been here a lot since V2 launched. Between the lack of an upgrade discount (which I do not care about but others clearly do) to the buggy "features" (which everyone cares about), I hope the devs are of stronger minds/constitution than me.

    I am here to basically second this thread, and to add to it.  Hopefully this is the right place to do this.

    With the cohesive integration of the three apps as well as the iPad and desktop versions, we need much better default file locations options.

    I am now saving my project files to iCloud so I can access them on both iPad and pc.

    Since I have hundreds of projects saved, I am exporting final images to a separate folder, just for basic organization.

    At a minimum, I kind of expect default options for saving/opening project files and a default folder for exporting images.

    For reference, below (or attached) is the "Preferences: Directories" page from Audacity, a free program.

    Audacity.jpg.02d38e6eee60238b07fb1bef3883e003.jpg

     

    Again, though, let me emphasize that Affinity has a great suite of programs that almost single-handedly keeps me from giving my hard-earned money to those f**kers at Adobe.

    Sincerely:  Thank you all for your ongoing and continued efforts.

    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. 

  5. On 11/15/2022 at 9:51 AM, Murfee said:

    This may work for you & others but there are also many others who prefer the last saved file location.

    I am all for user choice so a preference to decide & set would be the best option, if this current behaviour is changed and made default it would break the workflow of many users

    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. 

  6. 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/

  7. On 11/9/2022 at 6:03 PM, criffel said:

    I had my hopes when I saw the announcement the other day for v2, but we are dissapointed yet again. It was the first thing I checked once I purchased it. While it doesnt change my buying decision, I will just never understand why they cant give us the option to have the export settings linked to the file instead of the last settings that were used. Even Canva.com realizes this is an important feature and the give you a checkbox to save the export settings in the export workflow.  

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

  8. On 2/14/2021 at 9:46 AM, loukash said:

    I hate to repeat myself, folks, but:

    On 12/24/2019 at 4:30 PM, loukash said:

    On Mac, this is actually a system function. Open/Save dialogs are provided by the OS. The OS also keeps track of last places and writes the location into the respective application's preferences file (*.plist).

     

    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.

  9. On 2/13/2021 at 1:24 PM, Dan C said:

    Hi @Martin Deters,

    Welcome to the Affinity Forums and my apologies for the delayed response here!

    I can confirm that this issue is still with our developers to be resolved currently, as we're working directly with Apple to try and speed up the launch times of our apps on Big Sur. We suspect this is due to the new checks that Big Sur run when launching an app, however this is yet to be confirmed.

    As you've mentioned, this appears to only affect the first run of the application from a cold boot and any subsequent launches are faster.

    Some customers have reported duplicating the Affinity app, so that there are 2 versions, and the second version launches much faster on first launch - however this is not true for all users and isn't explicitly a workaround we're suggesting.

    We do hope to have an update to resolve this shortly, however I have no further information to provide currently, my apologies. 

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

  10. 4 minutes ago, Chapit Zulkefli said:

    Thanks, Affinity for hearing us. 
    This helps me a lot.

    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. 

  11. 4 minutes ago, walt.farrell said:

    If you continue to use the Affinity applications you will need to get used to Image layers, and how to deal with them.

    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. 

  12. 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.

  13. On 3/10/2020 at 4:33 PM, walt.farrell said:

    Good suggestion.

    A couple of workarounds for now, that you might consider:

    1. Select the image on the page using the Move Tool, and use the Replace Image button on the Context Toolbar, rather than using the Resource Manager.
    2. In the Resource Manager, click the Page # column to sort by Page # rather than image name.

    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.

  14. @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. 

  15. 9 hours ago, Gabe said:

    We've always advised to work LOCALLY and only use network drives for backup. 

    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. 

  16. 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.

  17. 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.

  18. 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 

  19. 17 hours ago, Chris B said:

    Hey robinp,

    Does this happen in the Photo Persona and do you have any other filters/adjustments? Can you perhaps attach the file for me?

    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. 

×
×
  • Create New...

Important Information

Terms of Use | 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.