Medical Officer Bones

The market is saturated with excellent animation applications.
Just a few production-ready alternatives for Animate CC (in no particular order):
OpenToonz, CelAction2D, Moho Pro, ToonBoom Harmony, TVPaint, After Effects, Fusion/Nuke, Blender (with Grease Pencil animation)... And these are only the start, with many lower-level apps out there, as well as 3d animation software which can also be used for 2d animation (Maya, etc.).
Tough market to compete and survive in. Serif probably feels the same, and is not planning a dedicated animation app.
 
 

I would consider this a bug, not a feature request. Windows version is also affected. Imagine this situation: the file dialog is smaller than one of the GUI panels. The user attempts to save the file, mis-clicks, and the file dialog is hidden beneath that panel.
Unless the user is aware of what just occurred, the user may assume that the app no longer responds. Showstopper!
This can be categorized as a user interface BUG, not a feature request.
I have NEVER experienced similar behaviour before in any Windows or Mac app. This is a first! Very interesting oversight on the part of the developers.
Definitely should be categorized and labelled as a bug.
...and I am going to use this as another clear example in my UX design classes of "How Not To Design A User Interface". I've got a couple of other great Affinity GUI examples which are already part of that list.

 

If palettes obscure open/save dialog boxes it is certainly a bug. Or maybe an oversight.

Anyway, open/save dialog boxes should always be on top. That is how users expect software to work. 

For those who want to try this out for themselves, the upcoming Blender 2.8 (beta can be downloaded) includes Cryptomatte as well - for free! And with the built-in compositor it is easy to convert these cryptomattes to masks.
Download the 2.8 beta here: https://www.blender.org/2-8/
 
 

I need 1-bit support for my comics and illustrations. Currently I use PhotoLine for this, which surprisingly has perfect support for this, even better than Photoshop or any other image editor out there:
works with layers(!) Meaning, unlike Photoshop it's no problem to combine multiple 1bit layers. can be combined in a single document with RGB or CMYK 300ppi layers and create a top 1bit 1200ppi layer PDF output in PhotoLine keeps it all intact, and outputs a proper PDF file. The 1bit 1200ppi layer is retained, and the colour work maintains a 300ppi output. InDesign also works well with this, but I no longer rent that software. The only other software I found so far (other than QuarkXPress) that supports a good 1-bit workflow is PhotoLine. And I know of no other image editor that supports a layer-based workflow with 1-bit graphics.
I am hoping that Affinity Publisher will support this workflow as well, but so far no cigar. I think all Affinity products ought to support a 1-bit workflow to make this work out properly anyway. (And an 8-bit indexed colour mode is missing in action as well in Affinity Photo, btw!)

I need 1-bit support for my comics and illustrations. Currently I use PhotoLine for this, which surprisingly has perfect support for this, even better than Photoshop or any other image editor out there:
works with layers(!) Meaning, unlike Photoshop it's no problem to combine multiple 1bit layers. can be combined in a single document with RGB or CMYK 300ppi layers and create a top 1bit 1200ppi layer PDF output in PhotoLine keeps it all intact, and outputs a proper PDF file. The 1bit 1200ppi layer is retained, and the colour work maintains a 300ppi output. InDesign also works well with this, but I no longer rent that software. The only other software I found so far (other than QuarkXPress) that supports a good 1-bit workflow is PhotoLine. And I know of no other image editor that supports a layer-based workflow with 1-bit graphics.
I am hoping that Affinity Publisher will support this workflow as well, but so far no cigar. I think all Affinity products ought to support a 1-bit workflow to make this work out properly anyway. (And an 8-bit indexed colour mode is missing in action as well in Affinity Photo, btw!)

I need 1-bit support for my comics and illustrations. Currently I use PhotoLine for this, which surprisingly has perfect support for this, even better than Photoshop or any other image editor out there:
works with layers(!) Meaning, unlike Photoshop it's no problem to combine multiple 1bit layers. can be combined in a single document with RGB or CMYK 300ppi layers and create a top 1bit 1200ppi layer PDF output in PhotoLine keeps it all intact, and outputs a proper PDF file. The 1bit 1200ppi layer is retained, and the colour work maintains a 300ppi output. InDesign also works well with this, but I no longer rent that software. The only other software I found so far (other than QuarkXPress) that supports a good 1-bit workflow is PhotoLine. And I know of no other image editor that supports a layer-based workflow with 1-bit graphics.
I am hoping that Affinity Publisher will support this workflow as well, but so far no cigar. I think all Affinity products ought to support a 1-bit workflow to make this work out properly anyway. (And an 8-bit indexed colour mode is missing in action as well in Affinity Photo, btw!)

I need 1-bit support for my comics and illustrations. Currently I use PhotoLine for this, which surprisingly has perfect support for this, even better than Photoshop or any other image editor out there:
works with layers(!) Meaning, unlike Photoshop it's no problem to combine multiple 1bit layers. can be combined in a single document with RGB or CMYK 300ppi layers and create a top 1bit 1200ppi layer PDF output in PhotoLine keeps it all intact, and outputs a proper PDF file. The 1bit 1200ppi layer is retained, and the colour work maintains a 300ppi output. InDesign also works well with this, but I no longer rent that software. The only other software I found so far (other than QuarkXPress) that supports a good 1-bit workflow is PhotoLine. And I know of no other image editor that supports a layer-based workflow with 1-bit graphics.
I am hoping that Affinity Publisher will support this workflow as well, but so far no cigar. I think all Affinity products ought to support a 1-bit workflow to make this work out properly anyway. (And an 8-bit indexed colour mode is missing in action as well in Affinity Photo, btw!)

I need 1-bit support for my comics and illustrations. Currently I use PhotoLine for this, which surprisingly has perfect support for this, even better than Photoshop or any other image editor out there:
works with layers(!) Meaning, unlike Photoshop it's no problem to combine multiple 1bit layers. can be combined in a single document with RGB or CMYK 300ppi layers and create a top 1bit 1200ppi layer PDF output in PhotoLine keeps it all intact, and outputs a proper PDF file. The 1bit 1200ppi layer is retained, and the colour work maintains a 300ppi output. InDesign also works well with this, but I no longer rent that software. The only other software I found so far (other than QuarkXPress) that supports a good 1-bit workflow is PhotoLine. And I know of no other image editor that supports a layer-based workflow with 1-bit graphics.
I am hoping that Affinity Publisher will support this workflow as well, but so far no cigar. I think all Affinity products ought to support a 1-bit workflow to make this work out properly anyway. (And an 8-bit indexed colour mode is missing in action as well in Affinity Photo, btw!)

I need 1-bit support for my comics and illustrations. Currently I use PhotoLine for this, which surprisingly has perfect support for this, even better than Photoshop or any other image editor out there:
works with layers(!) Meaning, unlike Photoshop it's no problem to combine multiple 1bit layers. can be combined in a single document with RGB or CMYK 300ppi layers and create a top 1bit 1200ppi layer PDF output in PhotoLine keeps it all intact, and outputs a proper PDF file. The 1bit 1200ppi layer is retained, and the colour work maintains a 300ppi output. InDesign also works well with this, but I no longer rent that software. The only other software I found so far (other than QuarkXPress) that supports a good 1-bit workflow is PhotoLine. And I know of no other image editor that supports a layer-based workflow with 1-bit graphics.
I am hoping that Affinity Publisher will support this workflow as well, but so far no cigar. I think all Affinity products ought to support a 1-bit workflow to make this work out properly anyway. (And an 8-bit indexed colour mode is missing in action as well in Affinity Photo, btw!)

I would like to add my voice to the requests for 1-bit support. I run the design / pre-press department of a printing company. We do spot-color offset and letterpress. I absolutely need 1-bit support for our workflow. Please, folks! This is a very important part of print production!
Thanks!

Literally the very first thing I tried to do with Affinity Designer was to drop a 1-bit logo file into a blank document. It was a bit disappointing to realize that I'd just bought a graphic design app that can't handle company logos or barcodes.
In InDesign or Illustrator you can just drop a bitmap logo / drawing into a document and change its fill to any color (very handy for designs that require spot colors). The bitmaps keep their crisp 1200 dpi resolution (and don't get anti-aliased) when exported to PDFs. It's a very hassle-free and effective way of working.
Am I just old-fashioned? Is there some new way of dealing with this stuff in Affinity Photo / Designer / Publisher that I'm just not aware of yet?
Every alternative suggestion I've seen on the forums has been far too complicated for what needs to be done. Following those suggestions would also lead to losing the benefits of working with 1-bit bitmaps anyway, resulting in downsampled and lossily compressed images in PDFs. Adobe's software offers separate downsampling settings for color, grayscale, and bitmap images, Affinity squashes all and everything with equal measure. That makes Affinity apps simply unsuitable for some print workflows, despite all the fantastic features they have. 
I'm aware that proper 1-bit color support might be technically more challenging to implement than it sounds, as it comes with the requirement to treat different image files placed in the same document in a different manner. That would probably pose new challenges for drawing the images on the screen too. And the PDF engine is probably a big hurdle too, since it is a third-party solution (as far as I know), and not flexible enough?
 
It would be nice to hear the developers' view on bitmap support. What's the reasoning for leaving it off the roadmap? Is it going to be added later (together with better tools to work with spot colors, maybe), or has the decision been made that it's simply not going to be supported and old-fashioned geezers like me should look elsewhere? Affinity Publisher's release is going to attract even more people fed up with Adobe's pricing model looking for alternative software. The lack of bitmap support might be a decisive factor for many, more critical than the design tools themselves. Some software can't deal with CMYK. Affinity stumbles with 1-bit images.
 
(I probably sound like a broken record at this point, having written many posts about this subject already. Sorry about that.)

For me just middle mouse button for panning + wheel for zoom is so much faster. Maybe as I do a lot of 3D, too, and those are what I set in any 3D app, so the comfort when switching apps is great, avoiding "disconnection".

Most of those are related to the lack of database/server connectivity. Pinegrow does have a similar project manager as Wappler, although Wappler can use FTP to connect with your webhost folder.
I did try out Wappler, and the GUI is still very VERY behind compared to Pinegrow. For example, in Pinegrow the same page or different pages can be viewed for various devices simultaneously, side by side. The interface in Wappler is almost completely static, and panels cannot be moved around. The styling controls in Pinegrow are far more user friendly and better exposed for CSS than the ones in Wappler.
It is one thing to compare and cherry pick base features between applications, but an altogether different thing to actually experience how these are implemented, and how the overall workflow and GUI respect the user's preferences. Pinegrow is light years ahead of Wappler in terms of configuration. And supports a live connection with Atom and MS Visual Studio Code for code editing. And many more things related to front-end development which are unavailable in Wappler.
The main difference between the two is that Wappler can connect to live data in a database, which Pinegrow cannot. However, Pinegrow does support direct WordPress theming in the WP edition, which allows for quick WP theming, and via WordPress data does become live. Wappler does not support WordPress. Via WordPress a tremendous library of free and commercial plugins for just about any requirement opens up. While Wappler allows the user to create their own custom database functionality, in comparison the WP ecosystem delivers just about any database functionality you would ever need. And WordPress delivers a user-friendly back-end interface out of the box, while in Wappler you would have to develop it yourself (and you'd never be able to match it on your own).
Pinegrow's WP edition supports custom data bindings through the Advanced Custom Fields WordPress plugin (which then pretty much delivers what Wappler delivers). But getting this far with the WP edition requires a good understanding of how WP theming works. Wappler is much easier to understand and learn in this respect.
So it really depends on what your needs are. Pinegrow is a much more mature application, in particular for front end development and its interface and workflow is quite flexible and adaptable to users' preferences, and Wappler offers custom database connectivity, but as an application still needs a lot of growing up in my opinion.
In short, don't rely on those cherry-picked feature comparison lists from either side. Test for yourself, and allow for a week of testing for each product.

I think you are missing the point I made: as you say, PDF is meant as a (final) export file format. As such, all the original structure and organization of the original file is lost, and while having the option to import PDF is great (in particular for singular pages and designs), the Publisher developers seem to treat PDF as a sort of intermediate format that they assume can be made to work as a viable alternative such as IDML: a true intermediate format that retains the structure for the most part.
And IDML is the only existing candidate file format which is already used as an intermediate DTP file format by various layout software, if perhaps mostly for import. What I am saying here is that IDML is really the only viable option, even if it is an Adobe format, because it is an open standard and relatively easy to support.
PDF can never work as an intermediate format for longer complex layout documents. Not if the user intends to heavily modify them. That is why I view Affinity Publisher and PhotoLine (which has supported the import of entire PDF documents for editing in a similar way) as capable PDF editors, but not as editors which can work with PDF-based structured documents. That is just not possible. And that is aside from all the other issues which I listed in the earlier post. Try editing a table after importing it via PDF.
Here is a question for you: would you prefer a PSD or a PDF of the same layered file to work with? Most users will probably opt for the PSD, because it retains the structure of the original. More, it IS the original. PSD import and export is supported by most image editors, even if many native PS features are not.
Or what about a Word file or a PDF version of that same Word file? A preposterous question, of course: anyone who wants to edit a document knows that the PDF is nigh on useless for this, and will choose the Word file. All word processing software worth its salt support Word import and export.
Likewise, IDML is a worthy candidate as a intermediate file format, and is indeed already supported as a general import format by most DTP layout software. Which is why I think IDML should not only be importable in Publisher, but also exportable.
@MikeW Scribus supports IDML import only at this time. The community is thinking about integrating IDML export as well. Viva Designer Pro supports my argument here: that company is smart enough to understand the simple concept that InDesign is the industry standard, and that IDML is a good intermediate format. Supporting it is the way to go. PDF is just not a viable alternative for all the reasons I explained.

With Atom and Pinegrow you do get the 2-sided workflow: select an item in the visual view, and Atom highlights the code part. Vice versa, in Atom place the cursor in an element, and hit CMD+ALT+P, and it highlights the element in Pinegrow.
Type in the code, and it updates the visual views in Pinegrow. Change something in Pinegrow, and the code updates in Atom.
Server-side PHP, ASP works as well, but must be activated in the library and component manager. The support is okayish for front-end work, but indeed needs more work.
Changing one's core workflow and tool pipeline is always a hassle, I agree.

Unfortunately, Affinity "remembers" tool or colour settings for each separate document, and will not use your colour settings between documents. That is just how Affinity seems to work.
As a work-around, save the colour as a colour swatch, and select the colour swatch when switching between documents. A new document or image that is opened will always reset the colours to black and white.
Frustrating, I agree. As far as I can recall, Affinity is the only design software which displays this behaviour. I wouldn't really know why this workflow would be preferable: to me it also makes little sense. Resetting to the default colours seems more like how a developer would solve this, rather than an artist or designer.

Depending on the source, Linux market share falls somewhere under the 2% margin. A checked a couple, and they tend to fall around %1.7-8?  It is only part of the story: I think it is not enough to merely take OS market share percentages at face value: that is why I also mentioned that only a subset of Linux users would be interested in a commercial professional design application. Only a fairly small percentage of all users would be interested in investing the time and effort in learning a full-on professional level design application. Most users could not care less.
The Mac platform is far more popular with graphic designers than Windows is, which explains why companies such as Adobe and Affinity invest in a platform which lingers around a deceptively small 10% desktop platform share.
Windows is almost 90% of the desktop market, and while the relative percentage of graphic design users is probably far lower compared to Mac, the brute force of the numbers of users will more than balance out the difference.
Linux has a far lower percentage of graphic design users than Windows AND a tiny market share. Is a market like that viable enough to jump in for Affinity or Adobe? I think both have done market research, checked the numbers, and their current Mac and Windows stats, and decided it is too much of a risk.
I do think that if you are a game or app developer working on a development system that easily exports a Linux version, you would be daft not to cash in on that as long as you develop from the start on deploying on all platforms. But even in that case Linux fragmentation causes headaches to make sure your game / software runs on a broad enough range of Linux systems. And then there's the graphic driver issues between platforms, and Apple's OpenGL deprecation in favour of Metal.
If Affinity code base could be directly converted to Linux, it might be worth it. But as it stands, the Mac and Windows versions use different GUI layers (as I understand it), and Linux would add a third one. Then to realize how long it took for the Affinity team to port to Windows...
It is quite understandable why Serif is avoiding the fragemented Linux desktop platform. I wish it would not be so, but I myself wouldn't put myself in that risky business venture. Perhaps first focus on getting the Mac and Windows version up to version 2 or 3, and then take a second look at the market.
Although at this point I tend to agree with the assertion that Linux is a failed desktop OS. Unless a miracle occurs, or MS and Apple pisses off their global user bases in a dramatic way, this will remain the case.
Linux is extremely successful in other areas, of course. Civilization would come to a standstill if Linux would disappear overnight. But as a mainstream desktop platform for designers? Unfortunately not.
 
 

@SrPx Your experience is identical to mine. I tried to switch friends and family to Linux, mainly because the only tasks involved were web browsing and a spot of text processing. Almost no-one liked it, and asked for Windows or Mac after a while. The sole exception is my wife, who works on a simple laptop which used to run WIndows 10, and now runs Linux Mint. But the only reason she continues to use it, is because I am always there to help her out with technical issues and updates. Without me, she wouldn't know, and prefer Windows (even though it runs much slower on that machine).
The one thing I HAVE been successful in convincing others to switch to: LibreOffice, Blender, and Krita. I actually got an entire college to adopt Blender for general 3d work, and so far almost every friend or family member is no running LibreOffice, without issues. And Krita has been adopted by various students as well.
But as I stated earlier, and SrPx points out as well, software is only a tiny factor in choosing a desktop platform, or a mobile platform It does indeed run deeper.

This is anecdotal. In two decades of working with web/graphic/screen/game designers and developers (both Europe and North America) and teaching thousands of students from all over the globe, I perhaps saw a handful of Linux users. In the past five years I haven't encountered any student in a digital design related program using Linux.
It's either Mac or Windows for the by far majority of these type of users, simple as that. Young design students just do not see Linux as an alternative. I have had trouble enough to get them to try open source alternatives like Krita!
That's not saying I would not like to see Adobe and Affinity release their software on Linux, far from that. I think if they would, Linux would become a more attractive choice for a certain sub-set of designers. I would make the switch, for example. But the fact is, no-one I've ever met and worked with in graphic/screen/mobile/web design related fields worked with the Linux platform. And I myself am very much the exception: barring one or two people, I haven't spoken to any designers who would even consider the switch to Linux (most don't even know what "Linux" is!).
I agree it's a bit of the chicken and the egg problem. But that doesn't take away the issue that the Linux desktop space is tiny compared to Windows and Mac, and the fact that the desktop/laptop design folks prefer Mac and Windows. Or that the Linux desktop space is so terribly fragmented. Even Linus admitted last year (more or less) that Linux as a desktop platform is its own worst enemy because of the fragmentation. As has been mentioned earlier in this thread, it would make more sense to invest in a ChromeOS version.
Linux in various shapes and forms is super-wide adopted all over the world in many situations, far more than either Windows or Mac; except for mainstream desktop users and certainly not in the world of graphic/web/general design.
Tiny adoption rate as a platform & tiny subset of target users  = no hope in heck to earn back your investment over a semi-long term.

If this is implemented, those layer properties must also include an anti-aliasing on/off option. I've worked with many image editors, and the only one I am aware of that offers this level of control on a per-layer basis is PhotoLine. Would be nice to have in Affinity as well.
@Steps Psenda's suggestion is not as crazy as it sounds. Pure black and white (monochrome) images, for example, should be printed at 800~1200dpi, so a document could consist of layers with varying resolutions. Unfortunately none of the Affinity products support monochrome bitmaps at this point. Another reason why a layer setting for PPI would be handy is when a lower resolution image is imported at (for example) 72ppi (based on its PPI parameter) and by quickly changing the PPI layer setting to 300ppi its size is automatically set to the exact resolution required for 300dpi print.
Some layout and image editing applications actually have this an an option for objects to simplify the workflow.

There indeed lies the major problem in this whole thing. I think I spoke about it earlier. You can be easily amazed about the vast quantity, and quality of all sort of developments , libraries and etc for network, scientific, database, security, etc in the Linux community, on its ecosystem. I mean, that kind of power, that complexity, perfection, attention to almost every sub field in those areas...the love to detail in many of those apps, IDEs, network utilities, etc, etc..!!... makes you realize they DO have enough programmers, and extremely talented. Now, apart from the holy three in 2D (Gimp, Inkscape, Scribus...and yeah, some more, but am talking this kind  of stuff) , there's Blender, and some more in 3D. I'm speaking in all these areas about OPEN SOURCE development, as, they don't need for example in those other areas, network, systems, scientific, etc, really to be all the time porting versions of apps from Windows or Mac. Theirs are often even better than the closed source commercial ones.   

The comparison is even cruel. Between the effort, resources, events, money, and people's volunteer time, and code in the other areas, specially system, network, and what is dedicated to graphics production software at more than a hobbyist level.  Again, not talking about if some company of closed source nature decides to graciously divert some resource to port one of their commercial apps to linux. Not talking about charity, but the fact of how they DO have capable people inside the community to produce graphic software that could beat any commercial grade solution, and beyond. It is my suspect that simply, Linux community has an EXTREME minority of people REALLY interested in commercial grade graphics production. Look, I've had a majority of Linux users among the people I used to go out with (and a bit later, also the people I worked with at an intensive/stressful company, that meant spending most of my time among Linux people) life was strange, and... NOT A SINGLE ONE could do a simple graphic. They'd require my help in that even for the silliest thing you could imagine. Heck, they still do!.  And they came from quite different jobs and areas, they were simply gathered by a pair of friends of mine. 

This is the root of the issue, in my opinion. You don't have to look for external factors, neither blame a third party which produces since always Windows (ie, Serif's legacy line) and Mac software. It's inside, both the problem and the solution. I am absolutely positive that all those brains and expertise, or heck, a 10% of it, would put together more than one Photoshop killer. If they really wanted to. So, no egg or chicken dilema, more of a wake up to the internal reality, and start to pull some strings from inside... There's already Blender, and Krita, as extremely good examples of what can be done with just a few decided programmers. (Krita's case is a really tiny group).
Can you imagine 2D apps made with the quality and level of completion of, let's say, current Thunderbird ?  I mean, I've seen entire staffs using that as the main thing for all inside a company. Or firefox, or etc... I'd said before that Libre Office does not get well with my friends and family... but as someone has pointed out, graphic artists and any professional has a bit of (not always, you'd be amazed... some super experts in PS I know, get stuck with zipping a file or if you tell them to PASTE a line in a term window (console in windows)) higher stamina when issues or bad UIs make appearance. So, even something at the level of Libre Office would make a world of difference in graphics production. (maybe Blender is kind of comparable, here). But not only is not there even a decent small % of interest in going that route, it's way worse: The current few apps in that line, get even worse press from inside, the community, than from the expected "enemy", the other platforms. Which always shocks me to a great extent. 

Depending on the source, Linux market share falls somewhere under the 2% margin. A checked a couple, and they tend to fall around %1.7-8?  It is only part of the story: I think it is not enough to merely take OS market share percentages at face value: that is why I also mentioned that only a subset of Linux users would be interested in a commercial professional design application. Only a fairly small percentage of all users would be interested in investing the time and effort in learning a full-on professional level design application. Most users could not care less.
The Mac platform is far more popular with graphic designers than Windows is, which explains why companies such as Adobe and Affinity invest in a platform which lingers around a deceptively small 10% desktop platform share.
Windows is almost 90% of the desktop market, and while the relative percentage of graphic design users is probably far lower compared to Mac, the brute force of the numbers of users will more than balance out the difference.
Linux has a far lower percentage of graphic design users than Windows AND a tiny market share. Is a market like that viable enough to jump in for Affinity or Adobe? I think both have done market research, checked the numbers, and their current Mac and Windows stats, and decided it is too much of a risk.
I do think that if you are a game or app developer working on a development system that easily exports a Linux version, you would be daft not to cash in on that as long as you develop from the start on deploying on all platforms. But even in that case Linux fragmentation causes headaches to make sure your game / software runs on a broad enough range of Linux systems. And then there's the graphic driver issues between platforms, and Apple's OpenGL deprecation in favour of Metal.
If Affinity code base could be directly converted to Linux, it might be worth it. But as it stands, the Mac and Windows versions use different GUI layers (as I understand it), and Linux would add a third one. Then to realize how long it took for the Affinity team to port to Windows...
It is quite understandable why Serif is avoiding the fragemented Linux desktop platform. I wish it would not be so, but I myself wouldn't put myself in that risky business venture. Perhaps first focus on getting the Mac and Windows version up to version 2 or 3, and then take a second look at the market.
Although at this point I tend to agree with the assertion that Linux is a failed desktop OS. Unless a miracle occurs, or MS and Apple pisses off their global user bases in a dramatic way, this will remain the case.
Linux is extremely successful in other areas, of course. Civilization would come to a standstill if Linux would disappear overnight. But as a mainstream desktop platform for designers? Unfortunately not.
 
 

They wouldn't. And Linux HAS design software that is very good (like Krita). But barring David Revoy, I haven't seen masses of digital painters move to Linux. He is the exception to the rule. I have seen quite a few digital painters move to Krita, but stay with their OS.
In my experience, the availability of (niche) software by itself is probably not a major or viable reason to switch to a different OS platform. Much more is needed than that to make the switch (whether from Mac to Windows, from Windows to Mac, or from those to any Linux variant).
When Affinity Photo was released for the Mac, many Windows users lamented the fact that it wasn't available for their OS. How many of these users made the switch to the Mac platform just because Affinity was available? Right, a negligible number, if any worth mentioning. Instead, they waited until it became available for their Windows platform.
Software doesn't seem to be a major driving factor to switch to a different OS for designers, or most mainstream users. If it were, graphic designer wouldn't care about the platform they work on, but reality tells us something very different: Mac is preferred. So other reasons take precedence.
Thinking that the availability of Affinity would increase Linux adoption rates across mainstream desktop users or artists/designers is most probably an oversimplification of a much more complex set of real-world factors. I don't think it would make even a small dent.