JGD

Just a teensy little bump to this thread… I'm guessing implementing the underlying frameworks needed for this format must be easier said than done, but it's something all kinds of users (be they designers/illustrators doing posters with loads of decoration who may wish to use some wild font like this: https://twitter.com/typotheque/status/933797656966717446 , or typesetters working on long, complex documents in the upcoming Publisher who may wish to have a finer control over their text styles) will have a use for, and… we mustn't forget this is a font file format we're talking about. Serif devs pride themselves in the wide, industry-standard format support offered by Affinity apps (and I'd venture to say the advent of variable fonts is a tiny revolution in the making and they will become an industry-standard sooner rather than later), and this should come way ahead than other tools in your list of priorities. People can always get around the lack of a certain tool by, say, using an older version of a CS app for a specific workflow (personally, performing image tracing in CS5 and exporting them to Designer, or re-doing spot colour gradients before exporting stuff to press come to mind), or by devising some other convoluted workflow inside Affinity apps alone, but not being able to use a format outright can be a deal-breaker for many people. Thus, not supporting these may equate to handing down potential clients/users to Adobe on a platter, I'm afraid. Then again, I'm extremely biased as I'm a Typography MFA student. But I'd still say typography and all things related rank (or at least they should rank) *extremely* high on most designers' priorities. On photographers' and illustrators', not so much, and we all know there's this weird oxymoronic dichotomy between Affinity Designer and Adobe Illustrator, wherein the former seems to be more geared towards illustrators (the strong emphasis you put on illustration in your choice of sample files is living proof of that – seriously, you only feature five files, “Edit '16”, “Artboards”, “Prison of Arts”, “Forma Playing Cards” and “Orbit”, which include typed text at all, and it's not much for that matter and on the last one, which is probably the one which features the most text, and on at least the other two before that which weren't set in Helvetica/Arial, it's all converted into outlines –, and perhaps you've even entered a feedback loop where you can't really get neat demos of graphic examples with text anymore because users aren't just submitting them or, worse even, creating them at all in the first place… or is that all on you and your curation? If so, if you do really have a choice, I feel it's a bit misguided to feature illustrations disproportionately, IMHO, and I'd be more than happy to submit some examples of my own, even if they have to be converted to curves, or even design some examples from scratch with web- [and OS-] safe fonts) and the latter more geared towards designers (even though they do the same with their splash screens, their type tools are now, much to my chagrin, second to none) and even wannabe technical draughtsmen (guilty as charged!), but c'mon guys, please honour your app's name a bit more.

I think another issue here with the Studio is the fact that it doesn't have a main, top group header like the Adobe CS/CC panels have (you know, the one with the x/close and chevron/collapse buttons). With their current scheme, you can clearly and easily click and drag: a) one individual panel, b) a sub-group of tabbed panels by clicking to the right of the last tab, or c) a super-group made up of sub-groups (either stacked vertically or horizontally) of panels by clicking said header. Affinity apps, on the other hand, have to sort of figure out the users' intentions on their own. As you can see from my video, that method seems to work good enough when just dragging them around in the middle of the screen, but they end up breaking apart and regrouping in weird, undesirable and irreversible ways when reaching the edges and triggering the snap-to-the-edges translucent overlay (or is it the inter-monitor transition that triggers it? I can't seem to be able to figure it out, because the two phenomena go hand-in-hand). Once you reach that state, it's game over, as leaving it isn't very forgiving. And boom, it's back to either manually putting everything back into its right place, or force-quitting the app again to reset them in one fell swoop. Oh, by the way and if I may add, you can only drag the whole Studio super-group if you grab onto the top-left tab/panel sub-group, which can be troublesome if you have too many tabs on said sub-group. The space between the rightmost tab and the panel properties (in case the currently selected tab features one) is so small a clickable target that more often than not you end up selecting the rightmost tab instead and dragging it out of the sub-group by accident. Affinity apps should, thus, have a hard-coded gutter between those interface elements, to allow for easier sub-group and super-group drag operations.

So… yeah, those videos are now up and posted in the appropriate thread. I see that even though those Studio issues are not completely fixed yet, you've been making some good progress. Kudos and thanks for looking into it.

So, yeah, here are a couple of updates on the state of RC1. It seems that my complain about the gutters has been addressed, yay! But moving the panels manually is still less than optimal… In case you're wondering, the second time when I clicked and dragged the panels back and forth between screens, I never let go of the mouse button; they just went crazy on their own. On the other hand, we finally have Fitt's Law working in our favour, as moving the cursor along the y axis further than the edge of the monitor no longer wreaks havoc. Now, if only they were as stable on the x axis when being moved across monitors…

I mean, I know it's apparently unrelated, but the wording is exactly the same (“bla bla because permission was denied”). Oh, actually (my bad!), it's when *saving* .txt files (after having saved them properly several times before, with them still open) that I get the error. But still, in 15 years of using Mac OS X/OS X/macOS I had never seen that error message before. And I did check file ownership/permissions. Pardon my ignorance, but I just gave some feedback because I have no idea whether that's a hard-coded but bog-standard Affinity Designer message, or a system-produced one. Anyway, I get why some people have been complaining about stability/usability issues on the Mac side of things, as I've been getting those lately too… It's nothing critical, but nagging nonetheless. Just see the other thread I'm posting on about multiple monitors, it has bothered me for years now (by the way, on that topic, this RC1 reverted to the earlier, less-than-optimal but still not-as-bad behaviour; it would be nice if I could drag the whole studio panel grouping back to its rightful monitor without it going crazy and regrouping in undesirable ways; I may make a small video showing it in action).

Just a heads-up: Affinity Designer never gave me this error message, but TextEdit *is* indeed showing it very often when opening .txt files (via double-clicking, in my case). Maybe it's related to iCloud Drive or some other issue in macOS (again, in my case, in Sierra)? By the way, the files usually open perfectly fine after quitting the app and reopening it.

AHA! Eureka! I seem to have found a common pattern! Whenever Affinity Designer or Photo is the current, topmost application, whether it has open windows or not, its panels will also move from one screen to the other when I turn off the secondary monitor or the whole setup goes into sleep mode, yes (and the Betas will exhibit that extra-garbled behaviour), but they *will* always revert to their proper place. It doesn't help me much personally, because I'd have to remember to always switch to either one before putting my Mac to sleep (and believe me when I say that's a usability issue; I always have a lot of open apps and I would consistently forget about that, as I already did when it came to quit them, which I thought was the only remedy), and if I have both open [and it's only bound to get worse once Publisher comes out], with open documents… at least one of them [or, when Publisher *does* come out, two of them] will end up with a messed up studio, and force me to save everything (even if I don't want to because of… reasons) and force quit it [them] to make it right again. But maybe that helps you or Apple to isolate the issue. By the way, I've been fooling around with my iTunes mini player window (one of the affected by this bug), and I think I finally figured Apple's API for multiple monitors and window positioning upon screen disconnection. It works as follows: at first, upon turning off a secondary monitor, windows will jump from their current coordinates on monitor 2 to the exact same coordinates on monitor 1, taking the top-left corner as the origin; but then, macOS, trying to be all user-friendly and whatnot, moves the window to the closest possible coordinate so as to have its right – or left, depending on screen arrangement – edge adjacent to the corresponding edge – and former inter-monitor boundary – on the main screen, and adjusts the y coordinate according to said screen arrangement, to make it seem as if the window was “pushed” from the secondary screen into the main one, instead of superimposed (like in a “flatten layers” command, using a photo editing analogy). The thing is, sometimes something ends up completely borked in the process (especially if the app, in Affinity's case, isn't the topmost one; so much for multitasking!), and I believe it's up to Apple to figure out why. Also, I noticed that *some* older apps, like Singer Song Reader (which I have always open underneath my iTunes mini player, right under the Up Next list so I can seamlessly toggle between said list and that lyrics viewer/fetcher), don't seem to honour that “being-pushed-from-the-other-side” behaviour (even though it sometimes ends up in the right place after turning the screen on, and sometimes it doesn't, as if macOS “forgot” about the y axis readjustment, and so does iTunes and Adobe apps, because I obviously configured my arrangement to make mouse movements as seamless as possible even with the slight PPI difference between both screens), which leads me to believe that this API is either a recent development, or something that developers have to actively implement. I should also add that this app, though apparently out-of-date, is already a 64-bit app, so it must've been coded in Cocoa, which means this isn't a Carbon vs. Cocoa issue (or so I think; could it still be?). Oh, I should also add that, per iTunes' behaviour and when turning the secondary monitor off and on again, Illustrator and InDesign always end up with their panels on the “wrong” x coordinates (i.e. zero; they stick to the left-hand side of monitor 1, just like they would on monitor 2) but on the right y coordinates (i.e. more than zero, accounting for monitor arrangement, so… they show an “in-between-ish” behaviour), and Photoshop gets the y coordinates right and tries to do so with the x ones as well to simulate said “pushed-from-the-other-side” thing but fails miserably, because the panels edges aren't adjacent to the right edge of the monitor (in fact, only 1/3 of them is visible, because Apple has decided to crop out-of-view elements instead of showing the rest on the secondary monitor ever since they came up with Mission Control and solved the conundrum of having multiple desktops in multiple monitores with, dare I say it, nearly enough aplomb, if not for these weird-ass bugs). Also, none of them revert to their proper positioning when turning the monitor on, so it seems that Affinity apps are, indeed, better coded in that regard, as they behave somewhat like Apples' first party ones, but would be perfect if they did so even without being the topmost app when waking up from sleep, and would be even better if they matched Adobe's customisable Workspaces (and, of course, allowed for an also customisable keyboard shortcut for resetting/toggling between them). I know that instead of being a full-blown permanent bug fix, going the Workspace route would be a palliative, and a temporary and incomplete solution that could end up becoming permanent, but seeing that you *may* be dependent on Apple to get this right, please do consider implementing those features if all else fails. Or even regardless of that, because they could indeed be useful for some professionals, as adding more and more Personas may not be the right way to go about managing different workflows or be enough (or desirable) for some people. Take, for instance, eclectic designers who work both for print and UI, and who Affinity seems to be tailored to or to encourage to become and do just that; they would likely love to have both print-bound and UI-bound custom workspaces, with the same Personas customised for different functions/jobs. That would keep the apps simple for *most* customers, and allow a certain subset of pro users to make it more complex if they really need it. Plus, it would make Affinity a better choice for multi-user office/school environments, where sysadmins, art directors and/or educators may not wish, for some reason, to configure separate, full-blown OS user accounts for separate people, and make their life easier if they need to reset workspaces/preferences, or copy them over from one machine to another (and, no, copying preferences from weird iCloud/MAS app ~/Library/Containers/* folders is *not* user-friendly at all, I'm afraid; cumbersome and archaic as Adobe's products may be – even going so far as sometimes requiring full preference resets to open at all because they become corrupted –, their Workspace tools are indeed useful); I speak from experience, as I had to give workshops at the Mac Room in my Faculty back when I was a monitor there: those tools are indeed useful in that kind of setting.

Great! Now I can't even reproduce it on my own main setup, even after waiting for the computer to fully go into sleep. I absolutely, positively, hate this kind of bug. If it was predictable and easily reproducible, I could probably learn how to live with it, but it consistently catches me off-guard and I haven't been able to precisely pin-point what's causing it so as to at least avoid it.

Hi again, Steve. Thank you for looking into the issue… This seems to be a tricky one. :\ I suspect this should really be escalated to Apple (or at least it could be useful to involve them in the conversation in some way or let them know of our findings). You see, I can't seem to reproduce the issue on my MacBook connected to the crappy Crown TV, but other people are complaining of the same thing, on different brands of monitors, and also with different apps. If I had to venture a guess, Occam's Razor tells me that the trigger is most likely a timing issue (it seems that the secondary monitor is taking too long to wake up, and macOS just thinks “eff it, I'll just slap these around elsewhere”); what doesn't look as clear cut is the reason why afterwards some windows revert to their proper positioning, some don't, and some do end up on the right monitor but shuffled around. You'd think that macOS would do all of this [near-]instantly, and not in separate steps, one app at a time, or that it would have some mechanism to be able to put them in the right place even if you forcibly disconnected and reconnected the screen or turned it off and then on, but… alas, if it has one, it's messed up in some serious ways. Oh, actually… it *does* have one. I just turned my monitor off, and the palettes promptly jumped to the left-hand side of my main screen as a snapped-on bloc (as they did on the MAS release), then shortly after jumped to the right-hand side immediately as separated entities with said gutters (as they do on the latest Designer and Photo betas). But when I turned it on again, everything reverted back to normal. What. the. hell. I will do some further testing on my part, and try other computer-monitor combinations as well as cleanly turning the monitors off and on (during normal usage, after the wake-from-sleep bug manifests itself, etc.), and let you know how it went.

Oh, I should also add that I also have a spare screen just like this one lying around (I ordered two, one for my and one for my father, but he didn't like having it connected to his MacBook Pro and never made much use of it, so it's just sitting on a desk at my parents' place as a dust-gathering back up in case this one fails, or in case I feel the need to use my own MacBook Pro over there instead of my main iMac setup), and two more Mini DisplayPort to HDMI + HDMI cable pairs to test with, in case you really think there may be something wrong with any of the individual components themselves. And I can use the MacBook Pro with the other one right away (it's an Early 2011 13'' model, also running macOS Sierra 10.12.6), as I said, and also with my cheap-ass 1080p Crown TV (its colour reproduction and contrast ratio are terrible and its PPI count low, and, to top it off, it has a ginormous bezel; that's why I would never consider using it alongside the iMac for any serious work, and in fact got it as a hand-me-down from my brother to plug into my cable DVR and other HDMI sources to watch video, and free up the Philips for precisely this secondary monitor use), to check whether I can reproduce the bug on other setups. My gut tells me there isn't (maybe with the monitor model, yes, but it seems to work just fine otherwise), but if you think it's worth giving it a shot, do let me know.

Hi Guys (@Andrew Tang, @steve_m)! I'm running macOS Sierra 10.12.6, on a 27'' Late '09 iMac, with an upgraded 2.93 GHz Core i9 and the original 512 MB ATI Radeon HD 4850. My external screen is a 24'' 1080p Philips LCD TFT, model no./ID 237E4LHSB/00, connected through a bog-standard HDMI cable and a Delock Mini DisplayPort to HDMI adapter. I mean, maybe it's something on my setup, but… I've been running external screens on Macs and they tend to flash a bit and be undecided about window positioning before they settle down. On the other hand, I don't remember the 21'' LG Flatron CRT I used to have connected to my 21.3'' iMac, back in 2010 when I was working on the Mac Room, ever doing that to Adobe CS5's palettes and other windows, so… Yes, maybe something is wrong with my setup, but I can't honestly guess what. macOS and other apps should really play nicer with standard components, and fully respect the Arrangement tab settings on the Display panel in System Preferences (otherwise, what good is that for?). As for the behaviour @VIPStephan mentioned, I didn't state it as eloquently (or at all), but I can confirm I also experience that, with Adobe apps, iTunes, and others, at least (not Affinity apps, though; those will always appear on the main monitor), their respective windows and panels will move to the proper monitor but to the wrong place (and I know I said they shift a bit, but “a bit” is a bit of an understatement, as sometimes entire panels will get cropped)…

Hi guys, I know it's at least the second time I'm complaining about this, but this time Affinity's behaviour is really irking me big time. Just to freshen up your memory (and because the earlier behaviour, while still undesirable, wasn't all that bad compared to the current one), last time I mentioned this nagging issue, this was what happened: When waking a dual-display Mac from sleep which had parts or the whole of the Studio on the secondary monitor, said panels were moved to the primary monitor, as a snapped-on block , in a similar location as they would appear on the secondary one (see screenshots “Designer” and “Photo”, below), which is conveniently located to the right of my main screen and only shifts the panels a bit from their default location. The only way to avoid this issue would be to quit Affinity Designer/Photo before putting the Mac to sleep, but at least if you forgot about that you could drag all of your panels to the secondary monitor. [By the way, while I'm at it, another bug/undesirable behaviour that I detected back then and which still hasn't been fixed in 1.5.x or in these 1.6.x betas is that if you drag the panel group from the topmost panel and push it even one pixel above the lower edge of the menu bar – regardless of whether you are doing it on the main monitor or on the secondary one –, the whole panel group will start breaking apart and grouping panel tabs in undesirable combinations all by itself, which is a serious abuse of Fitt's Law (it should be applied in useful functionality like hot corners, menus and other UX interactions like maximising or snapping, not semi-random, uncontrollable interactions that feel more like bugs rather than features; in this case, dragging the panel group against or above the menu bar should obviously result in, well, absolutely nothing besides it stopping its movement along the y axis).] Enter screwed-up scenario #2, under the 1.6.x betas: Now, when you wake up the Mac from sleep, the panels will reappear on the right-hand side of the primary monitor, in a semi-snapped state (they are not actually snapped but spaced with 5 px gutters between them), and some of them even lose their width info (I like to expand the Glyphs panel, for instance, so it opens up as a large window covering almost the entire remaining space in the secondary monitor, but it reverts to its default, minimum width) which screws up my setup even further (see screenshots “Designer Beta” and “Photo Beta”, below). Whereas before, I could just drag the whole thing back to its rightful place, now I have to either piece them all back together from scratch, or force quite the apps so they purge their current, unsaved – and patently undesirable – preferences and revert to their earlier state (which, while already an option before, is something I'd rather avoid doing, especially if I have open documents). To add insult to injury, InDesign, Illustrator and Photoshop CC do not even put the panels in the wrong monitor (they just shift them around a bit, but enough to render them unusable), and I managed to fix the issue by assigning an easy to remember keyboard shortcut (Cmd+Opt+hyphen) to the “Reset Workspace” command, which works a charm. I know this is actually a macOS issue (because besides Adobe apps, iTunes and other apps will sometimes also forget where they are supposed to draw their windows and shift them around the secondary monitor or redraw them on the main one) but please, oh please, can't you try to make Affinity play nice[r] with multiple monitor setups, on the Mac at least? There are a lot, and I mean *a lot* of professional Mac users who run such setups… And if you can't make it put the panels in the right monitor automatically (because macOS and its APIs, or its lack thereof), can't you at least make the apps revert to their older 1.5.x behaviour or implement some sort of Workspace functionality, to give us more advanced customisation management options and compete head-to-head with Adobe? [P.S.: I'll be sending Apple feedback on macOS and link to this topic thread; it's a damn shame that the OS which offers what is currently still the best multiple monitor support in the market can't get something as simple as this absolutely right and provide developers with the tools to do it as well].

Let me add my €0,02: expecting Serif to fully support all native .indd files is wishful thinking… But InDesign can currently export XML-based .idml format files (and used to export the equally XML-based .inx format files up until CS3), which should be easier to interpret or reverse-engineer by the Serif team. And since InDesign itself can open old files and most people who have a sizeable library of .indd files either have access to an older version of InDesign or can pay one month of an Adobe CC subscription without issue, converting all of your stuff from .indd/.inx/.idml to .afpub would be, in a best-case scenario, as easy as running a batch processing script. The only real issue I foresee with that kind of mass migration stems from Affinity Publisher's announced lack of a counterpart to Adobe Paragraph Composer on v.1.x; most of your converted .afpub documents won't look the same as the original (and they never would, even if and when Serif can come up with their own advanced typesetting subsystem) and will end up with a lot of overset text or other weird artifacts, I reckon… Personally, I do a lot of manual fine-tuning to tracking on a line-by-line basis to get rid of orphans and widows, so I'm dead sure most of mine would be (nay; will be, but I'm willing to live with that since I'll just be reusing layouts for new content) utterly screwed up after conversion.

Ohh, I see… I had a suspicion I was doing something wrong. Thank you for pointing that out!

(By the way, Apple seems to be lagging a bit behind itself with their own FCPX update, and it will take 10 years for most browsers to support those formats, so… do take your time. But I’d love to try them out on a proper DTP package sooner rather than later, if you know what I mean )

Hi MEB, Cool! Weirdly, a search on the forums for “HEIF” didn’t produce any results… And I don’t lurk much on the iPad forums, seeing that I only own a 3G/Retina. Thanks for the heads up!

Hi guys, Any thoughts on MPEG/Apple’s brand-spanking-new High Efficiency Image Format support? Affinity seems to be a logical choice for people who want to stay current on the latest and greatest standards, all with its fresh codebase and support for macOS-specific technologies… And let’s not forget about PC and iPad folks as well. Having Affinity support that format on all major platforms would greatly boost its adoption rate. What do you say?

Guys, you have a UI bug on light mode; some of the icons in the preferences window, on the drop-down menu, are not fully visible unless you hover above them. I'm guessing you kept the positive version unchanged, and the white on white parts are, thus, rendered invisible. Check it out:

Well, we'll have to agree on disagreeing. That would only make sense if the modifiers affected the action after the click, such as, say, the Alt-to-duplicate mid-drag operations on the Finder. In this particular scenario, pressing Alt does indeed switch to a different mode temporarily, and even though it sticks if you click and drag around for a brush selection, you absolutely must press Alt before clicking. Functionally, it works, yes, but the UX is *broken* because the UI does not fully reflect said changes as they are happening (and, no, as I said on another post, a tooltip is not enough to make it feel right *as you are using it*. Just because you, as a professional user, may get used to that, it doesn't make it any less broken). The right way would to give feedback be: press Alt, and the appropriate tab in each tool is highlighted; if you let go before clicking, it will revert to its default state, if you click and let go of Alt, it will still reflect their temporary state until you let go of the mouse/trackpad button, and if you don't let go of Alt, it will stay put until you do. Is this that hard to grasp and implement? It seems like a no-brainer, IMHO. Photoshop does this almost right (it isn't perfect because it only gives you the appropriate feedback after clicking, but at least it does eventually give you some UI feedback), while Affinity plainly doesn't even try to when using either the Brush Selection tool or the Refine Selection brush. This is one of those cases where Serif's attention to detail could very well allow them to, once again, one-up their competition.

Well, I'm running the Mac version, and I just checked on that. My bad, it really does, and thanks for pointing that out! I guess I was just distracted, maybe because of all the pressure I was under while doing that job. However, I still stand by the suggestions I made on this and the other thread. Though the “cheat-sheet” is indeed there on the status bar, I still think that the selection mode separator should reflect which modifier is pressed. And some sort of iconography next to the brush cursor outline would be a nice plus, too.

So this request is a follow-up to the one I made on this thread: Apparently, according to fellow forum user @toltec, this feature was already implemented, which is absolutely great. What is not so great, however, is its discoverability (or, in this case, its blatant [edit: partial] lack thereof). [edit: user @R C-R made me realise that the Status Bar already has a “cheat-sheet”/tooltip with said shortcuts, but I still feel that is not enough and that my suggestions are very sound, so please bear with me…] Please, for the sake of other users who may not frequent the forum or wish to spend hours perusing user manuals and tutorials (because this feature is, after all, something that pro users expect and may try for themselves [edit: even without, as was my case, paying any attention to the tips provided ], as it is a staple in brush tools not just in AP but also in other competing packages), make it [extra] visible and [even] more obvious. Basically, when pressing each modifier, please do make the appropriate tab (Matte | Foreground | Background | Feather) become temporarily highlighted/selected. This feature would, then, become easily discoverable to more seasoned users like myself, because as it stands, the UX feels “broken”. I mean, it will still feel that way to me even if I already know the feature is there, because visual feedback is just nice to have, as it shows that the app is working as it's supposed to. As it currently stands, you always display the same tab selection and, when pressing modifiers, you get a different, incongruous and non-explicit – even if completely desired – behaviour, which is indeed confusing, muscle-memory notwithstanding. It really is important for us to always have a “sense of place” when it comes to our tools. If I may offer another completely on-topic suggestion, I wonder if you could add some further visual feedback to the brush cursors themselves (and that would obviously be extensible to the Selection Brush tool), such as plus/minus signs floating outside of their outline (quite unlike their current behaviour in Ps – which centres them inside of said outline –, so as not to conflict with the cursor crosshair for those users who may have it configured to be visible)? I know that small as this suggestion may seem, it would add some visual clutter (I guess it could always be off by default and be selectable on the preferences dialog, just like the crosshair), but it I believe it would further enhance ease-of-use and differentiate AP from the competition. Thank you for your attention and keep up the good work!

Well, what do you know, @toltec, you are absolutely right! Thank you for your feedback! But now comes the hard part for Serif devs, who are never exempt from my cutting criticism. The feature is there, sure, but the UX is just disastrous (and that's why I was a bit skeptical at first about your reply, sorry ). It is not in the least bit discoverable, as the toggle *is not visible* to the user. It just magically happens behind the scenes with zero visual feedback. If the team had implemented that small but crucial detail, I would have found out immediately that pressing Alt was doing what I expected and this whole post would be moot. So, I'll either change the title of this request accordingly or, if that isn't possible, create a new one. [Edit: I went for the latter option; you can follow the new topic here: Make Refine Selection modifier-activated toggles visible to the user ]

Oh really…? Well, the last option seems to be just what I was looking for. Let me just check on it…

The title of the thread says it all: in AP, it would be nice if pressing Option toggled between one of the two additive selection brush modes (Matte or Foreground) and the subtractive mode (Background) in the Refine Selection dialog box. It's just that having to move the cursor or the pen back and forth just to change the selection mode gets rather tedious quickly and breaks the flow. Also, while on this subject, it would be nice if one could do further refinements without screwing up with other parts of the selection, but maybe it's just my workflow that isn't properly set up. Please bear with me, as I started transitioning to Affinity Photo in a production environment only very recently, and for now only when the tools I need are superior enough (the Refine Selection brush being one of them). IMHO, the greatest thing ever would be being able to just use the refine selection brush and the refine selection parameters independently of one another (or being able to undo them in separate steps in History), in order to achieve the most perfect selection possible. If only there was a way to use the brush without applying any effects, or certain effect slider values in said dialog box that produced zero changes and allowed me to refine the selection in many independent passes and apply said effects only when I was completely satisfied with it, I'd be a happy[ier] camper. That being said, the tool as it stands made one heck of a difference in a self-initiated emergency change, on a crazy-ass deadline (I could never have finished that in time using Ps, that's for sure), I made for a big project I just finished last month; I basically treated a landscape shot, which was used as the main theme on all media for an arts festival, in order to change the orange-y colour of the background clouds to a more neutral blue-gray independently of some trees in the foreground, because our country's forests had just started burning earlier that day – and have been burning almost continuously for a while now –, as leaving it untreated could mess with some people's sensitivities because it looked waaay too much like the photos and videos of said deadly fires circulating on the media. The only reason I didn't send this photo to you for your recent call for professional work done with AP was the fact that I do not own the rights to the original, and even though the author retroactively authorised the modifications I did to it after I explained him my reasoning behind them (I mean, given how serious the situation was, how could he not?), he didn't seem all too happy about the whole thing at first (especially considering that I did that on a rush, the night before sending that job to the print house, without consulting him first – I obviously negotiated it with our mutual client, which can ultimately propose and decide that kind of stuff at its sole discretion, but still), so I didn't even consider asking him for permission to share it with you. But anyway, I digress; Affinity Photo and my loyal Bamboo tablet saved the day and made doing this on a single all-nighter possible. Just to think that I could have saved some 10+ hours of work in a similar trees-vs-background selection task I did back in 2013, for the very same client, if only this app was available back then makes me value it even more because I now know how much more time I'll be able to save in the future… But I also know for a fact and from experience that I could save even more time if you implement that toggle shortcut.

I don't really think APFS will seriously mess with most apps… Stuff that deals directly with the file system, like file recovery (Disk Drill, Disk Warrior, File Salvage) and backup apps (SuperDuper, Carbon Copy Cloner), will most definitely break and require an update, but the rest? Apple would never pull off a smooth transition like the one from iOS 10.2 to iOS 10.3 if apps were really influenced by the change in the file system. As for the rest of what you said, well… No, it is not a waste of man power or money; allowing your users to upgrade to the latest major OS release if not on day one, at least shortly thereafter is part of any developer's job. That's why the really early-access builds are called *developer* builds… If anything, the latest stable release of Affinity apps, currently sold and distributed in the MAS, could and should run at least on the latest macOS *Public* beta or at least an attempt to make it run should be made. Public beta builds are always a bit behind closed developer-bound builds for a reason, you know? If you meant that these Affinity Customer Beta builds do not really have to run on macOS Public Beta or even the GM release on day one, well… I do agree with that. We are warned time and time again that these aren't intended for production purposes, only for testing, so we can't reasonably demand that. As for said MAS releases, as far as I can remember, Serif devs have made compatibility fixes to the current stable branch in the past, independently of the beta branch. I wouldn't be surprised in the least if we saw High Sierra-specific Affinity Photo 1.5.3 and Affinity Designer 1.5.6 builds hit the MAS on or around day one of the new OS release…